> On Sept. 25, 2016, 12:27 p.m., Jie Yu wrote: > > src/slave/containerizer/mesos/containerizer.cpp, line 705 > > <https://reviews.apache.org/r/52235/diff/1/?file=1509681#file1509681line705> > > > > Why the extra `!containerId.has_parent` check here? Will the first > > check implie the second check?
Just put a more accurate check on purpose > On Sept. 25, 2016, 12:27 p.m., Jie Yu wrote: > > src/slave/containerizer/mesos/containerizer.cpp, lines 800-812 > > <https://reviews.apache.org/r/52235/diff/1/?file=1509681#file1509681line800> > > > > Why having a separate look for extras? Can you just inline into the > > first loop? Let's keep creating of `Container` and insert into its parent > > close together. I did it on purpose, since it may be possible that the extra list from the `launcher->recover()` container parent-child relationship. However, that is a hashset. We cannot guarantee when we are adding the `containerId` to its parent children list, the parentContainerId exists in `containers_` already. > On Sept. 25, 2016, 12:27 p.m., Jie Yu wrote: > > src/slave/containerizer/mesos/containerizer.cpp, lines 743-748 > > <https://reviews.apache.org/r/52235/diff/1/?file=1509681#file1509681line743> > > > > We still need to call 'destroy' for a container that does not have pid > > to make sure it is properly cleaned up. > > > > ``` > > container->status = pid.isSome() > > ? reap(containerId, pid.get()) > > : Future<Option<int>>(None()); > > > > container->status->onAny(defer(self(), &Self::reaped, containerId)); > > ``` I handled the two cases as orphans: 1. no pid containers. 2. orphans from in the `extra` list from launcher->recover(). they are cleaned up at the end of contaienrizer::_recover(). why do we call `reaped()` and destroy twice? - Gilbert ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/52235/#review150344 ----------------------------------------------------------- On Sept. 24, 2016, 11:50 a.m., Gilbert Song wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/52235/ > ----------------------------------------------------------- > > (Updated Sept. 24, 2016, 11:50 a.m.) > > > Review request for mesos, Benjamin Hindman, Artem Harutyunyan, Jie Yu, Joseph > Wu, Kevin Klues, and Vinod Kone. > > > Repository: mesos > > > Description > ------- > > Supported mesos containerizer recover to be nested aware. > > > Diffs > ----- > > src/slave/containerizer/mesos/containerizer.hpp > 16f9e3e92e90fe7f8a0ebd24e567800e1f285bc9 > src/slave/containerizer/mesos/containerizer.cpp > 144b0db501d40d4e0bba12672723616bedd76e7e > > Diff: https://reviews.apache.org/r/52235/diff/ > > > Testing > ------- > > > Thanks, > > Gilbert Song > >
