[ 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)