[ https://issues.apache.org/jira/browse/MESOS-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Chen reassigned MESOS-2368: ----------------------------------- Assignee: Timothy Chen (was: Henning Schmiedehausen) > Provide a backchannel for information to the framework > ------------------------------------------------------ > > Key: MESOS-2368 > URL: https://issues.apache.org/jira/browse/MESOS-2368 > Project: Mesos > Issue Type: Improvement > Components: containerization, docker > Reporter: Henning Schmiedehausen > Assignee: Timothy Chen > > So that description is not very verbose. Here is my use case: > In our usage of Mesos and Docker, we assign IPs when the container starts up. > We can not allocate the IP ahead of time, but we must rely on docker to give > our containers their IP. This IP can be examined through "docker inspect". > We added code to the docker containerizer that will pick up this information > and add it to an optional protobuf struct in the TaskStatus message. > Therefore, when the executor and slave report a task as running, the > corresponding message will contain information about the IP address that the > container was assigned by docker and we can pick up this information in our > orchestration framework. E.g. to drive our load balancers. > There was no good way to do that in stock Mesos, so we built that back > channel. However, having a generic channel (not one for four pieces of > arbitrary information) from the executor to a framework may be a good thing > in general. Clearly, this information could be transferred out of band but > having it in the standard Mesos communication protocol turned out to be very > elegant. > To turn our current, hacked, prototype into something useful, this is what I > am thinking: > - TaskStatus gains a new, optional field: > - optional TaskContext task_context = 11; (better name suggestions very > welcome) > - TaskContext has optional fields: > - optional ContainerizerContext containerizer_context = 1; > - optional ExecutorContext executor_context = 2; > Each executor and containerizer can add information to the TaskContext, which > in turn is exposed in TaskStatus. To avoid crowding of the various fields, I > want to experiment with the nested extensions as described here: > http://www.indelible.org/ink/protobuf-polymorphism/ > At the end of the day, the goal is that any piece that is involved in > executing code on the slave side can send information back to the framework > along with TaskStatus messages. Any of these fields should be optional to be > backwards compatible and they should (same as any other messages back) be > considered best effort, but it will allow an effective way to communicate > execution environment state back to the framework and allow the framework to > react on it. > I am planning to work on this an present a cleaned up version of our > prototype in a bit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)