----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66668/#review202746 -----------------------------------------------------------
I checked the callers of `Containerizer::destroy()`, it seems no one actually cares about its return value (`Option<ContainerTermination>`), so why do we need to return that? Can we just make it return `Future<Nothing>`? src/slave/containerizer/composing.cpp Line 610 (original), 594 (patched) <https://reviews.apache.org/r/66668/#comment284748> Do we still need the `switch case`? It seems an `if else` is more readable. src/slave/containerizer/composing.cpp Lines 658-661 (original) <https://reviews.apache.org/r/66668/#comment284729> If we remove these codes, will the container be missed to delete and erased from `containers_`? - Qian Zhang On April 17, 2018, 11:23 p.m., Andrei Budnik wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/66668/ > ----------------------------------------------------------- > > (Updated April 17, 2018, 11:23 p.m.) > > > Review request for mesos, Alexander Rukletsov, Greg Mann, Jie Yu, and Qian > Zhang. > > > Bugs: MESOS-8712 > https://issues.apache.org/jira/browse/MESOS-8712 > > > Repository: mesos > > > Description > ------- > > Previously, we were using `destroyed` promise for each container to > guarantee that calling `destroy()` on a container returns a non-empty > value when the destroy-in-progress stops an launch-in-progress using > the next containerizer. Since we are unifying the semantics of the > return type for both `wait()` and `destroy()` operations, we can > remove the `destroyed` promise. > > > Diffs > ----- > > src/slave/containerizer/composing.cpp > 186102c66d373dcd799cadd9fed7d1c8cb894971 > > > Diff: https://reviews.apache.org/r/66668/diff/2/ > > > Testing > ------- > > internal CI > > > Thanks, > > Andrei Budnik > >
