Hi Vinod - this is good news! Just the fact that I'm not barking up the wrong tree and that indeed it is a known issue.
Cheers Jim On 11 June 2015 at 18:16, Vinod Kone <vinodk...@gmail.com> wrote: > > On Thu, Jun 11, 2015 at 4:00 AM, James Vanns <jvanns....@gmail.com> wrote: > >> I think I can conclude then that this just won't work; one cannot run a >> framework as a docker container using bridged networking. This is because a >> POST to the MM that libprocess does on your framework's behalf, includes >> the non-route-able private docker IP and that is what the MM well then try >> to communicate with? Setting LIBPROCESS_IP to the host IP will of course >> not work because then libprocess or somewhere in the mesos framework code >> an attempt at bind()ing to that interface is made and fails.... because it >> does not exist in bridge mode. >> > > You are right on track. This is a known issue: > https://issues.apache.org/jira/browse/MESOS-809. Anindya has submitted a > short term fix, which unfortunately never landed. I'll shepherd and commit > this. > > > >> *If* the above is correct then the question I suppose is why does the >> communication channel get established in that way? Why off the back of some >> data in a POST rather than the connected endpoint (that presumably docker >> would manage/forward as it would with a regular web service, for example)? >> Is this some caveat of using zookeeper? >> > > Longer term, the plan is for the master is to reuse the connection opened > by the scheduler and not open a new one, as you mentioned. See > https://issues.apache.org/jira/browse/MESOS-2289 > > > > >> I'm sure someone will correct me where I'm wrong ;) >> > > You are not! > > -- -- Senior Code Pig Industrial Light & Magic
