> On May 9, 2018, 11:15 p.m., Qian Zhang wrote:
> > 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>`?
And then for the last line of `ComposingContainerizerProcess::destroy`:
```
return container->containerizer->wait(containerId);
```
We could change it to something like:
```
return container->containerizer->wait(containerId)
.onAny([](const Future<Option<ContainerTermination>>& termination) {return
Nothing();})
```
- Qian
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66668/#review202746
-----------------------------------------------------------
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
>
>
