> On Oct. 9, 2016, 5:49 p.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?
> 
> Jing Chen wrote:
>     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.
> 
> Zameer Manji wrote:
>     You could extract out the logic in `serializeAdvertisement` to another 
> class and method and use it to get the same bytes that the Advertiser class.
> 
> Jing Chen wrote:
>     _serializeAdvertisement_ has **endpoint** and **additionalEndpoints** as 
> input from _lead_ method, but latches knows nothing about it during the 
> election

You can pass `endpoint` and `addtionalEndpoints` to the constructor of 
`CuratorSingletonService` via `CuratorDiscoveryModule` and not make them 
arguments to the `lead` method anymore. Then you will have access to them when 
the latches are created and can then serialize out the advertisements. Does 
that make sense? You might have to finagle with Guice a bit to get it to work.

If you join the [mesos](https://mesos-slackin.herokuapp.com/) slack and go to 
#aurora during day time PST, someone should be able to guide you with Guice 
questions.


- Zameer


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


On Oct. 9, 2016, 1: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, 1: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
> 
>

Reply via email to