[ 
https://issues.apache.org/jira/browse/MESOS-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600134#comment-14600134
 ] 

Yan Xu commented on MESOS-999:
------------------------------

So we ended up not taking on this.
Our motivation for addressing this was because with docker and other new 
containerization efforts such as MESOS-2386, some considerable amount of time 
can be spent on pulling and preparing the container images before the executor 
is launched so we don't want the slave to kill it due to a small 
{{--executor_registration_timeout}}.
While implementing this we realized that adding a slave level launch timeout 
flag doesn't solve the fundamental problem of the long image preparation having 
a noticeable impact on the slave and its tasks. We should instead working 
towards a solution that minimizes such impact.
The {{--executor_registration_timeout}} flag was originally introduced to 
account for the time required to fetch the executor so for now giving it a 
large value is the reasonable way for tasks that use container images.
Ultimately only the task knows what the expected preparation time is so such 
timeouts should probably go to ExecutorInfo or TaskInfo.

I feel like this ticket as it is currently phrased could be closed as {{Won't 
Fix}}. Do you agree [~idownes]?

> Slave should wait() and start executor registration timeout after launch 
> -------------------------------------------------------------------------
>
>                 Key: MESOS-999
>                 URL: https://issues.apache.org/jira/browse/MESOS-999
>             Project: Mesos
>          Issue Type: Bug
>          Components: isolation
>    Affects Versions: 0.18.0
>            Reporter: Ian Downes
>            Assignee: Yan Xu
>            Priority: Minor
>
> The current code will start launch a container and wait on it before the 
> launch is complete. We should do this only after the container has 
> successfully launched. Likewise for the executor registration timeout.



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

Reply via email to