[
https://issues.apache.org/jira/browse/MESOS-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14336118#comment-14336118
]
Henning Schmiedehausen commented on MESOS-2368:
-----------------------------------------------
Yes. The actual sketched change is here:
https://github.com/hgschmie/mesos/tree/mesos-psu (the tree is branched off
0.21.0). This is by no means production code (it barely compiles and there is
debug logging all over the place).
My goal is to make this code uniform so that any containerizer and executor can
add information onto a TaskStatus (currently, all we send back is our hacked
ContainerNetworkSettings element).
As I mentioned initially, what I need is to get status from the containerizer
back. And the more uniform, the more likely it is that we retain the middle
piece (== Mesos) when we replace the end piece (== Docker) with something else.
Let me whip up some code tomorrow that is in better shape (and against master,
not a tag) to illustrate what I want to do.
> 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: Henning Schmiedehausen
>
> 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)
