In the docker executor it can be done by the executor (once we have the docker executor, which makes this also easier).
That's what I'm trying to figure out as well, should I just reuse data or introducing a brand new field for this as it can have a specific meaning that it is container specific information. Probably using data is fine as it's expected to be arbitrary information passed from the executor back to scheduler. In the docker context, I'm also currently thinking it makes sense just to pass back the whole docker inspect JSON output back. Tim On Sat, Apr 11, 2015 at 4:57 PM, Vinod Kone <vi...@twitter.com.invalid> wrote: > 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) <j...@apache.org> 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)
