The weight of the labels transformation hasn't been a problem so far. In a second pass, we can put an upper limit (in seconds) to the hook/decorator and do it asynchronously. That will free the master actor up too.
If the slaves had permissions to get hold of the meta data themselves, then yes; we could have done another containerizer (and get it in without "any" changes with containerizer modules - TBD). However, only the master nodes can generate the meta-data that we need to track the tasks with. So that alone isn't enough. Niklas On 1 December 2014 at 12:46, Benjamin Mahler <[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. > > 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). > > > > > > > > >
