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!
