Do you have specific use cases in mind? Ie, specific actions that might take place pre and post launch?
On Thu, Nov 20, 2014 at 9:37 AM, Niklas Nielsen <nik...@mesosphere.io> wrote: > Hi everyone, > > > As a part of our current sprint at Mesosphere, we are striving to work on > and land an extension to the modules subsystem which we (per > https://issues.apache.org/jira/browse/MESOS-2060) have referred to as > ‘hooks’. We wanted to give some background to this feature and will be > asking for input to the proposal. > > The term is inspired by Apache Web Server hooks ( > http://httpd.apache.org/docs/2.2/developer/hooks.html) which allows > modules > to tie into the request processing life-cycle. It is different from the > existing modules capability, in that the usual request processing remains > untouched (and isn’t replaced fully as a regular module would do). > > In our case, we are interested in being able to tie into the life-cycle of > tasks to run pre and post-actions during task launch in the master and > slave processes. In general, it adds capability for all sorts of external > tooling and instrumentation. > The main idea is to enable modules to register themselves as hook > providers. For example through a new flag: --hooks=”module_name1, > module_name2, ...” > > A new ‘HookManager’ will query each module and get an object back of type ‘ > Hooks’ which has virtual member functions which points to the desired > callbacks in the module. > > > For example, > > class Hooks { > > public: > > virtual TaskInfo preMasterLaunchTask(TaskInfo task) = 0; > > virtual TaskInfo postMasterLaunchTask(TaskInfo task) = 0; > > virtual TaskInfo preSlaveLaunchTask(TaskInfo task) = 0; > > virtual TaskInfo postSlaveLaunchTask(TaskInfo task) = 0; > > // ... > > }; > > An example of the call site in Mesos could be: > > Master::launchTask(..., TaskInfo task, ...) > > { > > task = HookManager::preMasterLaunchTask(task); > > ... > > task = HookManager::postMasterLaunchTask(task); > > } > > We are not tied at all to how the hooks will be named (they could > potentially live in Master, Slave, Allocator, ...) subclasses, return Try, > Option, Result to indicate failure and so on. > > > > Introducing the hook functionality is similar to what we’ve done in the > past with Isolators for the MesosContainerizer that enables people to > provide new functionality for launching containers. In that same way, we > want people to be able to provide new functionality with respect to > launching tasks without changing the existing task flow. > > > We’d love to get people’s feedback so we can move forward! > > > Thanks, > Niklas > -- Dominic Hamon | @mrdo | Twitter *There are no bad ideas; only good ideas that go horribly wrong.*
