Hi again, (Sorry for the copy paste, but the discussion has been going on in both JIRA and this thread)
Just had a chat with BenH and Kapil, and think that we came up with a safer solution which would fit our needs (at the cost of some general flexibility). Here is the idea; instead of thinking about generic hooks which can change arbitrary fields in task infos (which may cause severe problems if, say resource fields are changed) we care about being able to 1) Have call-backs be invoked and 2) Tag tasks with meta-data in labels at several points during the task life-cycle. So instead of thinking about generic hooks, we wanted to talk about "Task Decorators" instead. Labels labels = LaunchTaskDecorators(task, framework, ...); task.mutable_labels()->CopyFrom(labels); Only const references to, say TaskInfo, FrameworkInfo and so forth is provided to the decorator. So the task processing remains untouched and only labels (which are not interpreted by Mesos) can be modified. We also need to be able to hang off data in the executor environments which, in turn, can be done with "Environment Decorators". The term "Decorators" was just our first thought on the name of the concept, but that is still open for discussion. On 25 November 2014 at 15:41, Niklas Nielsen <[email protected]> wrote: > > > On 24 November 2014 at 12:24, Vinod Kone <[email protected]> wrote: > >> On Fri, Nov 21, 2014 at 4:56 PM, Niklas Nielsen <[email protected]> >> wrote: >> >> > That aside, our use-case involves hanging meta-data off the task with >> > labels which we cannot do with an event stream alone. >> > The metadata we need is produced by a 3rd party security infrastructure >> > which we invoke and use when setting up the executor environment in the >> > slave. >> > We actually only need the pre hook / filter mechanism to do this, but >> > wanted to come up with a generalized solution. >> > >> >> I still don't quite understand the use case. Why can't a framework(s) talk >> to the security infrastructure and setup the TaskInfo appropriately and >> opaquely to master? It sounds like the executor(s) need to be modified to >> understand the updated security information anyway. >> > > The frameworks themselves doesn't not have permission to do that and it > needs to work transparently across frameworks that we may not know/control > how constructs task infos. > You are right that hooks need to be on both sides (on masters during task > launch and on slaves during executor launch). > >
