aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jing Chen <milantr...@gmail.com>
Subject Re: Review Request 52665: Populate curator latches with scheduler information
Date Wed, 19 Oct 2016 00:28:41 GMT


> On Oct. 10, 2016, 12:49 a.m., John Sirois wrote:
> > src/main/java/org/apache/aurora/scheduler/discovery/CuratorSingletonService.java,
line 142
> > <https://reviews.apache.org/r/52665/diff/1/?file=1528674#file1528674line142>
> >
> >     This was in my example code, but I don't think its the right answer for the
contents of the node; ie: Zameer was gunning for a unique ip such that he could cat the contents
of the `*-latch-*` nodes and from that learn which machines were contending for leadership.
 As things stand, that execercise might net the set `{127.0.0.1, 127.0.0.1, 127.0.0.1}` -
not terribly helpful!
> >     
> >     You may just need to enumerate all non-loopback addresses, like ~so:
> >     ```
> >     $ cat Address.java 
> >     import java.net.InetAddress;
> >     import java.net.InterfaceAddress;
> >     import java.net.NetworkInterface;
> >     import java.util.Enumeration;
> >     
> >     public class Address {
> >       public static void main(String[] args) throws Exception {
> >         for (Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
> >              interfaces.hasMoreElements();) {
> >           NetworkInterface networkInterface = interfaces.nextElement();
> >           if (!networkInterface.isLoopback()) {
> >             System.out.printf("Enumerating addresses of interface %s:%n", networkInterface.getName());
> >             for (InterfaceAddress address: networkInterface.getInterfaceAddresses())
{
> >               InetAddress inetAddress = address.getAddress();
> >               System.out.printf("\t%s: %s%n", inetAddress.getCanonicalHostName(),
inetAddress.getHostAddress());
> >             }
> >           } 
> >         }
> >       }
> >     }
> >     $ javac Address.java
> >     $ java -cp . Address
> >     Enumerating addresses of interface vboxnet0:
> >     	fe80:0:0:0:800:27ff:fe00:0%vboxnet0: fe80:0:0:0:800:27ff:fe00:0%vboxnet0
> >     	192.168.33.1: 192.168.33.1
> >     Enumerating addresses of interface docker0:
> >     	172.17.0.1: 172.17.0.1
> >     Enumerating addresses of interface wlp3s0:
> >     	fe80:0:0:0:183:9e44:9c10:9999%wlp3s0: fe80:0:0:0:183:9e44:9c10:9999%wlp3s0
> >     	10.0.3.132: 10.0.3.132
> >     ```
> >     
> >     I'm not sure of a more foolproof way pre-serverset-join to get useful addresses
regardless of machine setup. Joshua and Zameer likely have better ideas.
> 
> Zameer Manji wrote:
>     I commented on the ticket, that I think it would be best if the latches just had
the ServerSet information. If we did that, we would avoid these issues.
> 
> John Sirois wrote:
>     That may be slightly easier said than done since election preceeds joining (its a
singleton set).
> 
> Zameer Manji wrote:
>     Hmm, I thought we could make the bytes from the `Advertiser` class go into the `LeaderLatch`
consturctor?

Zameer, is it possible to get the bytes from the **Advertise** into the **LeaderLatch**? Per
my understanding, those bytes are generated in _advertise()_ after a leader is selected. Latches
are created before the election, those bytes are not ready yet during the latches creation.
John's code might be a solution because it reveals the reacheable ip address of the contenders.


- Jing


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/52665/#review151949
-----------------------------------------------------------


On Oct. 9, 2016, 8:43 a.m., Jing Chen wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52665/
> -----------------------------------------------------------
> 
> (Updated Oct. 9, 2016, 8:43 a.m.)
> 
> 
> Review request for Aurora, Joshua Cohen, John Sirois, and Zameer Manji.
> 
> 
> Bugs: AURORA-1785
>     https://issues.apache.org/jira/browse/AURORA-1785
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Populate curator latches with scheduler information
> 
> 
> Diffs
> -----
> 
>   src/main/java/org/apache/aurora/scheduler/discovery/CuratorServiceDiscoveryModule.java
e690d1448a900484ee9723bb8cd47def1a6db31d 
>   src/main/java/org/apache/aurora/scheduler/discovery/CuratorSingletonService.java 4040067a5301f71f35b6719b42fdf0ecbe282404

> 
> Diff: https://reviews.apache.org/r/52665/diff/
> 
> 
> Testing
> -------
> 
> verified in vagrant
> 
> (CONNECTED) /> get /aurora/scheduler/member_0000000051
> {"serviceEndpoint":{"host":"aurora.local","port":8081},"additionalEndpoints":{"http":{"host":"aurora.local","port":8081}},"status":"ALIVE"}
> (CONNECTED) /> get /aurora/scheduler/_c_5c25d2a0-7070-4fde-a50d-78364e763e9c-latch-0000000050
> 127.0.0.1
> 
> 
> Thanks,
> 
> Jing Chen
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message