You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Till Toenshoff (JIRA)" <ji...@apache.org> on 2015/02/14 06:05:11 UTC

[jira] [Updated] (MESOS-2335) Mesos Lifecycle Modules

     [ https://issues.apache.org/jira/browse/MESOS-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Till Toenshoff updated MESOS-2335:
----------------------------------
    Description: 
A new kind of module that receives callbacks at significant life cycle events of its host libprocess process. Typically the latter is a Mesos slave or master and the life time of the libprocess process coincides with the underlying OS process. 

h4. Motivation and Use Cases

We want to add customized and experimental capabilities that concern the life time of Mesos components without protruding into Mesos source code and without creating new build process dependencies for everybody. 

Example use cases:
1. A slave or master life cycle module that gathers fail-over incidents and reports summaries thereof to a remote data sink.
2. A slave module that observes host computer metrics and correlates these with task activity. This can be used to find resources leaks and to prevent, respectively guide, oversubscription.
3. Upgrades and provisioning that require shutdown and restart.

h4. Specifics

The specific life cycle events that we want to get notified about and want to be able to act upon are:

- Process is spawning/initializing
- Process is terminating/finalizing

In all these cases, a reference to the process is passed as a parameter, giving the module access for inspection and reaction. 

h4. Module Classification

Unlike other named modules, a life cycle module does not directly replace or provide essential Mesos functionality (such as an Isolator module does). Unlike a decorator module it does not directly add or inject data into Mesos core either.

  was:
A new kind of module that receives callbacks at significant life cycle events of its host libprocess process. Typically the latter is a Mesos slave or master and the life time of the libprocess process coincides with the underlying OS process. 

h4. Motivation and Use Cases

We want to add customized and experimental capabilities that concern the life time of Mesos components without protruding into Mesos source code and without creating new build process dependencies for everybody. 

Example use cases:
1. A slave or master life cycle module that gathers fail-over incidents and reports summaries thereof to a remote data sink.
2. A slave module that observes host computer metrics and correlates these with task activity. This can be used to find resources leaks and to prevent, respectively guide, oversubscription.
3. Upgrades and provisioning that require shutdown and restart.

h4. Specifics

The specific life cycle events that we want to get notified about and want to be able to act upon are:

- Process is created/instantiated
- Process is spawning/initializing
- Process is terminating/finalizing

In all these cases, a reference to the process is passed as a parameter, giving the module access for inspection and reaction. 

h4. Module Classification

Unlike other named modules, a life cycle module does not directly replace or provide essential Mesos functionality (such as an Isolator module does). Unlike a decorator module it does not directly add or inject data into Mesos core either.


> Mesos Lifecycle Modules
> -----------------------
>
>                 Key: MESOS-2335
>                 URL: https://issues.apache.org/jira/browse/MESOS-2335
>             Project: Mesos
>          Issue Type: Improvement
>          Components: master, modules, slave
>            Reporter: Bernd Mathiske
>            Assignee: Till Toenshoff
>              Labels: features
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> A new kind of module that receives callbacks at significant life cycle events of its host libprocess process. Typically the latter is a Mesos slave or master and the life time of the libprocess process coincides with the underlying OS process. 
> h4. Motivation and Use Cases
> We want to add customized and experimental capabilities that concern the life time of Mesos components without protruding into Mesos source code and without creating new build process dependencies for everybody. 
> Example use cases:
> 1. A slave or master life cycle module that gathers fail-over incidents and reports summaries thereof to a remote data sink.
> 2. A slave module that observes host computer metrics and correlates these with task activity. This can be used to find resources leaks and to prevent, respectively guide, oversubscription.
> 3. Upgrades and provisioning that require shutdown and restart.
> h4. Specifics
> The specific life cycle events that we want to get notified about and want to be able to act upon are:
> - Process is spawning/initializing
> - Process is terminating/finalizing
> In all these cases, a reference to the process is passed as a parameter, giving the module access for inspection and reaction. 
> h4. Module Classification
> Unlike other named modules, a life cycle module does not directly replace or provide essential Mesos functionality (such as an Isolator module does). Unlike a decorator module it does not directly add or inject data into Mesos core either.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)