mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zhitao Li (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MESOS-7874) Provide a consistent non-blocking preLaunch hook
Date Thu, 10 Aug 2017 00:01:30 GMT

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

Zhitao Li updated MESOS-7874:
-----------------------------
    Description: 
Our use case: we need a non-blocking prelaunch hook to integrate with our own secret management
system, and this hook needs to work under both {{DockerContainerizer}} and {{MesosContainerizer}},
for both {{custom executor}} and {{command executor}}, with proper access to {{TaskInfo}}
(actually certain labels on it).

As of 1.3.0, the hooks in [hook.hpp | https://github.com/apache/mesos/blob/1.3.0/include/mesos/hook.hpp]
pretty inconsistent on these combination cases.

The closest option on is {{slavePreLaunchDockerTaskExecutorDecorator}}, however it has a couple
of problems:

1. For DockerContainerizer + custom executor, it strips away TaskInfo and sends a `None()`
instead;
2. This hook is not called on {{MesosContainerizer}} at all. I guess it's because people can
implement an {{isolator}}? However, it creates extra work for module authors and operators.

The other option is {{slaveRunTaskLabelDecorator}}, but it has own problems:
1. Error are silently swallowed so module cannot stop the task running sequence;
2. It's a blocking version, which means we cannot wait for another subprocess's or RPC result.

I'm inclined to fix the two problems on {{slavePreLaunchDockerTaskExecutorDecorator}}, but
open to other suggestions.

  was:
Our use case: we need a non-blocking prelaunch hook to integrate with our own secret management
system, and this hook needs to work under both {{DockerContainerizer}} and {{MesosContainerizer}},
for both {{custom executor}} and {{command executor}}, with proper access to {{TaskInfo}}
(actually certain labels on it).

As of 1.3.0, the hooks in [hook.hpp | https://github.com/apache/mesos/blob/1.3.0/include/mesos/hook.hpp]
pretty inconsistent on these combination cases.

The closest option on is {{slavePreLaunchDockerTaskExecutorDecorator}}, however it has a couple
of problems:

1. For DockerContainerizer + custom executor, it strips away TaskInfo and sends a `None()`
instead;
2. This hook is not called on {{MesosContainerizer}} at all. I guess it's because people can
implement an {{isolator}}? However, it creates extra work for module authors and operators.

The other option is {{slaveLaunchTaskLabelDecorator}}, but it has own problems:
1. Error are silently swallowed so module cannot stop the task running sequence;
2. It's a blocking version, which means we cannot wait for another subprocess's or RPC result.

I'm inclined to fix the two problems on {{slavePreLaunchDockerTaskExecutorDecorator}}, but
open to other suggestions.


> Provide a consistent non-blocking preLaunch hook
> ------------------------------------------------
>
>                 Key: MESOS-7874
>                 URL: https://issues.apache.org/jira/browse/MESOS-7874
>             Project: Mesos
>          Issue Type: Improvement
>          Components: modules
>            Reporter: Zhitao Li
>            Assignee: Zhitao Li
>              Labels: hooks, module
>
> Our use case: we need a non-blocking prelaunch hook to integrate with our own secret
management system, and this hook needs to work under both {{DockerContainerizer}} and {{MesosContainerizer}},
for both {{custom executor}} and {{command executor}}, with proper access to {{TaskInfo}}
(actually certain labels on it).
> As of 1.3.0, the hooks in [hook.hpp | https://github.com/apache/mesos/blob/1.3.0/include/mesos/hook.hpp]
pretty inconsistent on these combination cases.
> The closest option on is {{slavePreLaunchDockerTaskExecutorDecorator}}, however it has
a couple of problems:
> 1. For DockerContainerizer + custom executor, it strips away TaskInfo and sends a `None()`
instead;
> 2. This hook is not called on {{MesosContainerizer}} at all. I guess it's because people
can implement an {{isolator}}? However, it creates extra work for module authors and operators.
> The other option is {{slaveRunTaskLabelDecorator}}, but it has own problems:
> 1. Error are silently swallowed so module cannot stop the task running sequence;
> 2. It's a blocking version, which means we cannot wait for another subprocess's or RPC
result.
> I'm inclined to fix the two problems on {{slavePreLaunchDockerTaskExecutorDecorator}},
but open to other suggestions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message