> On June 11, 2015, 7:34 p.m., Vinod Kone wrote:
> > 3rdparty/libprocess/src/process.cpp, lines 820-836
> > <https://reviews.apache.org/r/34128/diff/2/?file=963212#file963212line820>
> >
> >     If two libprocess based unix processes (e.g., scheudler and master) are 
> > within the *same* bridged container, would they able to communicate with 
> > this change? Can you test this to confirm?
> >     
> >     
> >     If not, a better option might be to instead have LIBPROCESS_BIND_IP and 
> > LIBPROCESS_BIND_PORT that just changes the address we bind to. 
> > LIBPROCESS_IP and LIBPROCESS_PORT semantics could be left untouched.
> 
> Anindya Sinha wrote:
>     If 2 libprocess based unix processes are running, they would point to a 
> different <public_ip:public_port> (most likely same public_ip but a different 
> public_port, ie. same LIBPROCESS_PUBLIC_IP but a different 
> LIBPROCESS_PUBLIC_PORT). The processes themselves would bind as it does today 
> on <ip:port> (based in LIBPROCESS_IP and LIBPROCESS_PORT). Once a request 
> lands on a corresponding <public_ip:public_port>, a proxy listening on that 
> would forward that to the actual <ip:port> corresponding to the 
> <public_ip:public_port>.
>     
>     As an example, mesos-master binds on 10.11.12.13:5050 (ip:port) with 
> public_ip:public_port as 192.168.100.100:6050, and say scheduler binds on 
> 10.11.12.13:8081 with public_ip:public_port as 192.168.100.100:9081. Requests 
> received on 192.168.100.100:6050 shall be proxied over to 10.11.12.13:5050 
> (to reach mesos-master) and requests received on 192.168.100.100:9081 shall 
> be proxied over to 10.11.12.13:8081 (to reach scheduler).
> 
> Vinod Kone wrote:
>     ```
>     a proxy listening on that would forward that...
>     ```
>     
>     who sets up this proxy? or do you mean this is what happens currently in 
> bridged mode containers (e.g., docker)?
> 
> Anindya Sinha wrote:
>     No this is not something that is part of docker. The proxy would be 
> something external to the container which would proxy the request to your 
> application within the container.
>     This patch enables external entities viz. zookeeper reach the host (based 
> on public_ip:public_port) from where a proxy will be required to route to the 
> application running within the container. If we use <ip:port>, zookeeper 
> won't be able to reach. The setting up of the proxy is not a part of docker 
> or libprocess.
>     Please also refer to relevant issue 
> https://issues.apache.org/jira/browse/MESOS-2587.

Can we get some inputs on this so as to move forward?
Please also look into https://reviews.apache.org/r/34129/ which is also a part 
of this fix.


- Anindya


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


On May 18, 2015, 10:08 p.m., Anindya Sinha wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/34128/
> -----------------------------------------------------------
> 
> (Updated May 18, 2015, 10:08 p.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-809
>     https://issues.apache.org/jira/browse/MESOS-809
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Expose environment variables LIBPROCESS_PUBLIC_IP and LIBPROCESS_PUBLIC_PORT 
> as the IP and
> port which libprocess would advertise (if set). If not set, it defaults to
> the IP and port on which it binded to.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/src/process.cpp 
> e3de3cd6b536aaaf59784360aed546512dd04dc9 
> 
> Diff: https://reviews.apache.org/r/34128/diff/
> 
> 
> Testing
> -------
> 
> Testing:
>   make test
> 
> 
> Thanks,
> 
> Anindya Sinha
> 
>

Reply via email to