[proposal] Module extension: hooks

2014-11-20 Thread Niklas Nielsen
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 f

Re: [proposal] Module extension: hooks

2014-11-21 Thread Niklas Nielsen
First off, thanks for all the comments! I really appreciate it and am excited about where we get with this effort. Let me see if I can answer your questions (best-effort inlined). On 21 November 2014 01:11, Tom Arnfeld wrote: > This all sounds really great, and opens up some interesting opportun

Re: [proposal] Module extension: hooks

2014-11-22 Thread Alex Rukletsov
I like the idea of a cluster event stream very much! With this feature implemented, we will be able to gather cluster health status, various statistics for on-the-fly or offline analysis. AFAIK, the only way to gather some stats now is to parse master and slave logs. As it looks for me, the event s

Re: [proposal] Module extension: hooks

2014-11-24 Thread Vinod Kone
On Fri, Nov 21, 2014 at 4:56 PM, Niklas Nielsen 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 u

Re: [proposal] Module extension: hooks

2014-11-25 Thread Niklas Nielsen
On 22 November 2014 at 11:02, Alex Rukletsov wrote: > I like the idea of a cluster event stream very much! With this feature > implemented, we will be able to gather cluster health status, various > statistics for on-the-fly or offline analysis. AFAIK, the only way to > gather some stats now is t

Re: [proposal] Module extension: hooks

2014-11-25 Thread Niklas Nielsen
On 24 November 2014 at 12:24, Vinod Kone wrote: > On Fri, Nov 21, 2014 at 4:56 PM, Niklas Nielsen > 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 sec

Re: [proposal] Module extension: hooks

2014-11-25 Thread Niklas Nielsen
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

Re: [proposal] Module extension: hooks

2014-12-01 Thread Benjamin Mahler
> 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 th

Re: [proposal] Module extension: hooks

2014-12-01 Thread Niklas Nielsen
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

Re: [proposal] Module extension: hooks

2014-12-01 Thread Benjamin Mahler
> However, only the master nodes can generate the meta-data that we need to > track the tasks with. So that alone isn't enough. Why can only the master obtain the information? I can understand making a distinction between mesos and the frameworks in terms of security. The distinction between mas

Re: [proposal] Module extension: hooks

2014-12-04 Thread Benjamin Hindman
> > Why can only the master obtain the information? > I think it's fair to say that an organization might prefer to limit the exposure of certain security credentials to fewer machines, such as just the masters. > My impression is that because these constraints are rigid, we are forced to > have

Re: [proposal] Module extension: hooks

2014-11-20 Thread Dominic Hamon
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 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 sub

Re: [proposal] Module extension: hooks

2014-11-20 Thread Benjamin Mahler
Thanks for sending this Nik! The general idea of hooks sounds good. I think the question for hooks is about which extensibility points make sense, and I think we'll have to assess that with the introduction of each hook. (1) Is the idea behind hooks about actions, as you initially mentioned? Or i

Re: [proposal] Module extension: hooks

2014-11-20 Thread Vinod Kone
Good points Ben. Also, I've been recently thinking about an events endpoint (not to confuse with the Event/Call API) that could stream all kinds of events happening the cluster (master events, allocator events, gc events, slave events, containerizer events etc). In fact this could probably be expo

Re: [proposal] Module extension: hooks

2014-11-20 Thread Benjamin Mahler
Glad you mentioned this, I was actually thinking of mentioning cluster event streaming as well :) I held back his example shows synchronous *transformation* of TaskInfo objects, would love to see if that interference is really required. On Thu, Nov 20, 2014 at 10:43 PM, Vinod Kone wrote: > Good

Re: [proposal] Module extension: hooks

2014-11-21 Thread Tom Arnfeld
This all sounds really great, and opens up some interesting opportunities for automated service discovery (well, the announcement side) for a cluster which is what we've been looking into for a while. Correct me if I'm wrong, but would it be possible to make use of the master log to achieve