[
https://issues.apache.org/jira/browse/MESOS-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14566950#comment-14566950
]
Timothy Chen commented on MESOS-2368:
-------------------------------------
commit b16999a4cb92ad35e97d29e7e99d897063f8bdca
Author: Timothy Chen <[email protected]>
Date: Sat May 23 22:47:49 2015 -0700
Send docker inspect output with TaskStatus data.
Review: https://reviews.apache.org/r/34654
> 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)
