> On March 22, 2016, 11:37 p.m., Avinash sridharan wrote:
> > src/slave/containerizer/mesos/isolators/network/cni/cni.hpp, line 151
> > <https://reviews.apache.org/r/45082/diff/1/?file=1307516#file1307516line151>
> >
> >     I guess if we are going to use `attach` for connecting to networks, 
> > lets use `detach` over here.

Agree.


> On March 22, 2016, 11:37 p.m., Avinash sridharan wrote:
> > src/slave/containerizer/mesos/isolators/network/cni/cni.cpp, lines 647-649
> > <https://reviews.apache.org/r/45082/diff/1/?file=1307517#file1307517line647>
> >
> >     This is a bit odd, __disconnect always returns an error ? The plugin 
> > can return error codes and error logs which we should be propagating 
> > upstream through failure semantics.

The reason that `__disconnect()` always returns a `Failure` is, it will be only 
called when the exit code of plugin is not 0 (i.e., plugin fails for a reason), 
in case of plugin success, we will return `Nothing()` in `_disconnect()`. So we 
only need `__disconnect()` in case of plugin failure to get the output (i.e., 
detailed failure reason) of plugin and propagate it upstream.


> On March 22, 2016, 11:37 p.m., Avinash sridharan wrote:
> > src/slave/containerizer/mesos/isolators/network/cni/cni.cpp, line 653
> > <https://reviews.apache.org/r/45082/diff/1/?file=1307517#file1307517line653>
> >
> >     Why are we returning a Future<list<Nothing>> over here? We should be 
> > returning a Future<Nothing> there is no list since you are deletnig the 
> > entire container directory in one shot. This seems a bit odd.

I tend to agree with you, however, I see CPU share isolator does the similar 
thing: 
https://github.com/apache/mesos/blob/0.28.0/src/slave/containerizer/mesos/isolators/cgroups/cpushare.cpp#L536:L547,
 maybe we should change it as well?


> On March 22, 2016, 11:37 p.m., Avinash sridharan wrote:
> > src/slave/containerizer/mesos/isolators/network/cni/cni.cpp, lines 644-645
> > <https://reviews.apache.org/r/45082/diff/1/?file=1307517#file1307517line644>
> >
> >     These two CHECKS don't make sense. What if the plugin got deleted or 
> > there was a bug in the plugin because of which it wasn't able to delete the 
> > interfaces or release the IP addresses. The Agent should not die because of 
> > an error in a 3rd party plugin.

If the plugin got deleted, then `Subprocess.isError()` will be true and we will 
return a `Failure`, if there was a bug in the plugin, then 
`Subprocess.status()` will be non-zero and we will read its output for the 
detailed error message. For either of these cases, agent will not die.


- Qian


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


On March 21, 2016, 12:30 a.m., Qian Zhang wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45082/
> -----------------------------------------------------------
> 
> (Updated March 21, 2016, 12:30 a.m.)
> 
> 
> Review request for mesos, Avinash sridharan, Gilbert Song, and Jie Yu.
> 
> 
> Bugs: MESOS-4759
>     https://issues.apache.org/jira/browse/MESOS-4759
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Implemented cleanup() method of "network/cni" isolator.
> 
> 
> Diffs
> -----
> 
>   src/slave/containerizer/mesos/isolators/network/cni/cni.hpp PRE-CREATION 
>   src/slave/containerizer/mesos/isolators/network/cni/cni.cpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/45082/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Qian Zhang
> 
>

Reply via email to