[jira] [Updated] (MESOS-7874) Provide a consistent non-blocking preLaunch hook
[
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 way to notify our secret management system
during task launching sequence on agent. This mechanism needs to work for both
{{DockerContainerizer}} and {{MesosContainerizer}}, and both {{custom
executor}} and {{command executor}}, with proper access to labels on
{{TaskInfo}}.
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 {{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.
> 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 way to notify our secret management
> system during task launching sequence on agent. This mechanism needs to work
> for both {{DockerContainerizer}} and {{MesosContainerizer}}, and both
> {{custom executor}} and {{command executor}}, with proper access to labels on
> {{TaskInfo}}.
> 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)
[jira] [Updated] (MESOS-7874) Provide a consistent non-blocking preLaunch hook
[
https://issues.apache.org/jira/browse/MESOS-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-7874:
--
Shepherd: Till Toenshoff (was: Till)
> 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)
[jira] [Updated] (MESOS-7874) Provide a consistent non-blocking preLaunch hook
[
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)
[jira] [Updated] (MESOS-7874) Provide a consistent non-blocking preLaunch hook
[
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 {{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.
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 {{masterLaunchTaskLabelDecorator}}, 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 {{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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
