Who sends the information? If it's the executor can it just not use 'data' field in status?
@vinodkone > On Apr 11, 2015, at 2:48 PM, Timothy Chen (JIRA) <[email protected]> wrote: > > > [ > https://issues.apache.org/jira/browse/MESOS-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491208#comment-14491208 > ] > > Timothy Chen commented on MESOS-2368: > ------------------------------------- > > I've started to think about this more, and I think having a generic way to > express container information back to the framework seems to be necessary > especially when the scheduler likes to do more advanced options with the > container that is spawned. Currently a scheduler cannot tell which container > is spawned by its task simply because there is no correlation that can be > made and scheduler doesn't know about the container id. > > What I'm thinking is perhaps we can expose a free form key/value pair that > are like labels, to be passed back as part of the TaskStatus update that is > container specific information. In the case of Docker, it can be the docker > inspect information that is extracted and exposed back, which will include > name, network, and other info. > > [~idownes] [~jieyu] what you guys think? > > > > >> 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)
