[ https://issues.apache.org/jira/browse/MESOS-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14507963#comment-14507963 ]
Timothy Chen commented on MESOS-2368: ------------------------------------- Renamed this issue as we are going to scope this ticket to just sending back docker inspect information back. So here is the planned implementation proposal: Once the new docker executor is merged, we can modify the docker executor that after running the container to send `docker inspect <container>` output in the first TASK_RUNNING StatusUpdate data field, and will only send this once. In the future if we introduce health checks for docker containers which we will send mulitple TASK_RUNNING updates, we will still only send it on the first status update. > Send Docker container information back to the scheduler > ------------------------------------------------------- > > 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)