> 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
>
>
|