LIBPROCSES_IP

2016-10-11 Thread Jie Yu
Hi folks, I was in the process of cleaning up some tech debt related to env variables in our code base. I created an epic ticket to track. I searched relevant tickets fired previously, and found MESOS-3740

Re: LIBPROCSES_IP

2016-10-11 Thread haosdent
> libprocess should always bind to 0.0.0.0 + 1 for this On Wed, Oct 12, 2016 at 2:33 AM, Jie Yu wrote: > Hi folks, > > I was in the process of cleaning up some tech debt related to env variables > in our code base. I created an epic ticket > to

Re: LIBPROCSES_IP

2016-10-11 Thread Avinash Sridharan
Definitely a +1 for executor binding to 0.0.0.0, instead of doing a `gethostname` and `getaddrinfo`. But I am assuming this semantics would kick in only if LIBPROCESS_IP is not set, which should be the norm. +1 for LIBPROCESS_ADVERTISE_IP and LIBPROCESS_ADVERTISE_PORT and the onus being on the fra

Re: LIBPROCSES_IP

2016-10-11 Thread Jie Yu
> > While I believe this particular logic of setting LIBPROCESS_ADVERTISE_IP > to agent IP can be done in the agent (it could look at the port mapping > as well) What if there are multiple port mappings? How can the agent decide which port to be used as LIBPROCESS_ADVERTISE_PORT? On Tue, Oct 11

Re: LIBPROCSES_IP

2016-10-11 Thread Avinash Sridharan
Valid point. Makes sense to drive this decision from the user and the framework. On Tue, Oct 11, 2016 at 9:32 PM, Jie Yu wrote: > > > > While I believe this particular logic of setting LIBPROCESS_ADVERTISE_IP > > to agent IP can be done in the agent (it could look at the port mapping > > as well

Re: LIBPROCSES_IP

2016-10-12 Thread Erb, Stephan
>Framework should be the one that sets >LIBPROCESS_ADVERTISE_IP and LIBPROCESS_ADVERTISE_PORT appropriately if it >tries to launch another Mesos framework so that Master can reach the new >framework. As a framework/executor author this is not possible in all scenarios: There is no way to discover

Re: LIBPROCSES_IP

2016-10-12 Thread Alex Rukletsov
> > Also, I think libprocess should always bind to 0.0.0.0, rather than doing a > hostname lookup and bind to the IP found for the hostname. > LIBPROCESS_ADVERTISE_IP can be used to overwrite the ip address it wants to > advertise to peers. If that's not specified, it'll try to do a hostname > look

Re: LIBPROCSES_IP

2016-10-12 Thread Jie Yu
Stephan, I think the only time the framework needs to set LIBPROCESS_ADVERTISE_IP is when DNAT is necessary for the container (e.g., bridge). In that case, LIBPROCESS_ADVERTISE_IP should always be agent ip and the relevant host port allocated for the container. For other cases, framework should no

Re: LIBPROCSES_IP

2016-10-15 Thread tommy xiao
good point, +1 2016-10-13 0:27 GMT+08:00 Jie Yu : > Stephan, > > I think the only time the framework needs to set LIBPROCESS_ADVERTISE_IP is > when DNAT is necessary for the container (e.g., bridge). In that > case, LIBPROCESS_ADVERTISE_IP should always be agent ip and > the relevant host port al

Re: LIBPROCSES_IP

2016-10-16 Thread Jie Yu
OK, guys. Thanks for the input! Here is my proposal: 1) If the container uses host network, Mesos agent will set LIBPROCESS_ADVERTISE_IP to agent IP. This is for the case where DNS is not configured properly on the host (we don't need to do that if DNS is configured properly). By doing this, libpr

Re: LIBPROCSES_IP

2016-10-16 Thread haosdent
Sounds great! >libprocess should always bind to 0.0.0.0 Do you proposal include this? On Mon, Oct 17, 2016 at 2:12 AM, Jie Yu wrote: > OK, guys. Thanks for the input! Here is my proposal: > > 1) If the container uses host network, Mesos agent will set > LIBPROCESS_ADVERTISE_IP > to agent IP. T

Re: LIBPROCSES_IP

2016-10-16 Thread Jie Yu
> > Do you proposal include this? If we don't set LIBPROCESS_IP, by default, it'll bind to 0.0.0.0. - Jie On Sun, Oct 16, 2016 at 7:09 PM, haosdent wrote: > Sounds great! > > >libprocess should always bind to 0.0.0.0 > > Do you proposal include this? > > On Mon, Oct 17, 2016 at 2:12 AM, Jie Y