> On Oct. 15, 2014, 12:15 a.m., Timothy Chen wrote:
> > src/docker/docker.cpp, line 472
> > <https://reviews.apache.org/r/26709/diff/1/?file=721122#file721122line472>
> >
> >     I'm not sure what executor timeout you're referring to, but for example 
> > the executor signal escalation timeout although similiar is not really 
> > intended for docker containerizer shutdown. In all our containerizers we 
> > simply kill (SIGKILL) the tasks.
> >     
> >     Let's rename the method and also make the timeout be a method param 
> > that we can pass in.
> 
> Ryan Thomas wrote:
>     Ok will do. I think we do need some sanity checking on the param though, 
> maybe we could just set a hard upper bounds on the value - 60 seconds?
> 
> Ankur Chauhan wrote:
>     Yes, I basically had this in mind (mind the TODO)
>     
>     ```
>       string cmd = path + " kill " + container;
>       if(os::hasenv("MESOS_DOCKER_STOP_TIMEOUT")) {
>         const string timeout = os::getenv("MESOS_DOCKER_STOP_TIMEOUT", false);
>         // check if it is there and is numeric
>         if(string != NULL && std::regex_match(timeout, std::regex("[0-9]+"))) 
> {
>           // it is numeric
>           // TODO: Verify the value us something sane
>           cmd = path + " stop -t " + timeout + " " + container;
>         }
>       }
>     
>     ```
>     
>     I definitely agree with Timothy's comment to rename methods and such. I 
> (personal opinion) wouldn't want to put in any hard coded values - but would 
> definitely support 60 secs as a good default value for a timeout.

Although it makes sense to not let a large timeout be specified, what large 
means seems subjective enough that I'm not sure what is a good upper bounds we 
can use.
My intuition is that we have the following options:
1) We set a default timeout to be a relative small number (ie 10-15) for now 
(with a constant), since it's already a expectation that we kill tasks so we 
don't want to have a huge shutdown.
2) Allow the timeout to be configurable and let the user adjust the best 
configuration

I'm not sure yet what's the best approach, but I think going for 2) will be the 
most flexible.

As for the option, let's expose it as a slave flag instead of using envrionemt 
variables here.


- Timothy


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26709/#review56611
-----------------------------------------------------------


On Oct. 14, 2014, 9:56 p.m., Ryan Thomas wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26709/
> -----------------------------------------------------------
> 
> (Updated Oct. 14, 2014, 9:56 p.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1925
>     https://issues.apache.org/jira/browse/MESOS-1925
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Change docker kill to docker stop to allow graceful shutdown of containers.
> 
> 
> Diffs
> -----
> 
>   src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
> 
> Diff: https://reviews.apache.org/r/26709/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Ryan Thomas
> 
>

Reply via email to