> On Feb. 12, 2014, 2:02 a.m., Tom Arnfeld wrote: > > src/slave/containerizer/pluggable_containerizer.cpp, line 388 > > <https://reviews.apache.org/r/17567/diff/2/?file=482402#file482402line388> > > > > Hmm. If the container hasn't launched and we disregard the update > > request, does this mean we're going to completely ignore a change to > > resources? > > > > Would it not make sense to pass the update request on to the external > > containerizer anyway and give them the opportunity to make this decision? > > The external containerizer might want to make note of "pending" resource > > changes and apply them once the container is up (or wait for the container > > to come up). > > Till Toenshoff wrote: > That could indeed be a valid and still persisting point. Will look into > that...
Should be fixed by the use of synchronizing PluggableStatus-protobuf result from launch - it should be sent once that launch has been accomplished. > On Feb. 12, 2014, 2:02 a.m., Tom Arnfeld wrote: > > src/slave/containerizer/pluggable_containerizer.cpp, line 595 > > <https://reviews.apache.org/r/17567/diff/2/?file=482402#file482402line595> > > > > Does this method assume killing the external containerizer process will > > successfully kill the container? In the case of docker, if you kill the > > `docker run` call it will certainly kill cleanly, but the container is > > still running. You need to execute a `docker kill XXX` command to cleanly > > kill the running container (which will exit non-0 if it fails). > > Till Toenshoff wrote: > Let me describe the now updated way of handling this situation; > We are sending a "destroy" command to the containerizer plugin first. The > plugin is then responsible to answer that command-request with a status. Once > that status has been received the PluggableContainerizer will signal a > SIGTERM (with SIGTERM elevation) towards the plugin. > > So the addition basically is a "wait for result/response" on destroy, > allowing for synchronized flows. > > Would that fit your needs? > > Tom Arnfeld wrote: > That makes sense. I've also realised this workflow is fine now that i've > implemented own containerizer. Note, I had removed the SIGTERM -> SIGKILL escalation as we need a centralized way of doing this. Also my initial implementation just wasn't good enough as it could possibly leave child process leaves within the process tree of the containerizer alive. - Till ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17567/#review34249 ----------------------------------------------------------- On Feb. 28, 2014, 1:23 a.m., Till Toenshoff wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/17567/ > ----------------------------------------------------------- > > (Updated Feb. 28, 2014, 1:23 a.m.) > > > Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Ian Downes, > Niklas Nielsen, and Vinod Kone. > > > Bugs: MESOS-816 > https://issues.apache.org/jira/browse/MESOS-816 > > > Repository: mesos-git > > > Description > ------- > > This patch adds the so-called pluggable containerizer. This > containerizer delegates all containerizer calls directly to > an external containerizer program (which can be specified on > start-up). Few calls have internal fall-back implementations > such as wait(), destroy() and usage(). > > The protocol for the interactions with the external program > is as follows: > > COMMAND (ADDITIONAL-PARAMETERS) < INPUT-PROTO > RESULT-PROTO > > launch (ContainerID, --mesos-executor, <path>) < TaskInfo > PluggableStatus > update (ContainerID) < ResourceArray > PluggableStatus > usage (ContainerID) > ResourceStatistics > wait (ContainerID) > PluggableTermination > destroy (ContainerID) > PluggableStatus > > When protocol buffers need to be provided, the Mesos side of > the pluggable containerizer will serialize the protos on stdin > and vice-versa for reading protos on stdout as drafted in the > above scheme. > > > Diffs > ----- > > configure.ac a8bc8a8 > include/mesos/mesos.proto 37f8a7f > src/Makefile.am 61d832b > src/examples/python/test-containerizer.in PRE-CREATION > src/examples/python/test_containerizer.py PRE-CREATION > src/slave/containerizer/containerizer.cpp d0a1023 > src/slave/containerizer/pluggable_containerizer.hpp PRE-CREATION > src/slave/containerizer/pluggable_containerizer.cpp PRE-CREATION > src/slave/flags.hpp e4d98a5 > src/tests/pluggable_containerizer_test.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/17567/diff/ > > > Testing > ------- > > make check and functional testing. > > > Thanks, > > Till Toenshoff > >
