[
https://issues.apache.org/jira/browse/MESOS-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120921#comment-16120921
]
Till Toenshoff edited comment on MESOS-7874 at 8/10/17 1:28 AM:
----------------------------------------------------------------
We do indeed split this work on hooks and isolators, depending on the
containerizer used.
The docker containerizer will at some hopefully not too distant point in the
future be deprecated in favor of the mesos containerizer. The same is true for
the command executor - we are working towards deprecating it in favor of the
default executor.
Introducing new hooks is generally something that we are trying to avoid, if
possible. We do however have a relatively low barrier in changing the signature
of hooks - so changing a formally blocking hook into a non blocking one
({{Future<...>}}) is something we have done before.
All this said, it seems we should try to aim for your second option by using
both an isolator and a hook.
was (Author: tillt):
We do indeed split this work on hooks and isolators, depending on the
containerizer used.
The docker containerizer will at some hopefully not too distant point in the
future be deprecated in favor of the mesos containerizer. The same is true for
the command executor - we are working towards deprecating it in favor of the
default executor.
Introducing new hooks is generally something that we are trying to avoid, if
possible. We do however have a relatively low barrier in changing the signature
of hooks - so changing a formally blocking hook into a non blocking one
({{Future<...>}) is something we have done before.
All this said, it seems we should try to aim for your second option by using
both an isolator and a hook.
> 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)
