> 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.
Consulting the 3rd party security infrastructure synchronously in the launch path sounds expensive..? I still have a hard time understanding the use case. Could this all just be implemented as a security isolator that consults the 3rd party security infrastructure? Or a containerizer that wraps our containerizer with the additional security requirements? On Tue, Nov 25, 2014 at 5:25 PM, Niklas Nielsen <[email protected]> wrote: > 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). > > > > >
