> On Jan. 15, 2016, 6 a.m., Cong Wang wrote: > > Why do we need netcls to regulate framework traffic on a per-container > > basis? Given the fact that a) the port range based filters already work and > > the code (see egress fq_codel) already exists b) we only have port range > > based network isolation so far. > > > > I see no point of this. Please describe your use case with details, just > > pointing to netcls kernel doc doesn't help at all. > > Cong Wang wrote: > Since no one answers this, I assume no one in Mesosphere actually > understands it... So looks like you are pushing something no one is actually > going to use. > > Avinash sridharan wrote: > The egress_fq_codel that you are pointing too (I am assuming this is the > jira you are refferring to https://issues.apache.org/jira/browse/MESOS-2422) > needs port mapping isolator to enforce QoS on any egress traffic > shaping/policing, and for that matter any network policy enforcement. > > The net_cls cgroup is a linux kernel construct that allows operators to > support traffic shapping/policing and any network policy enforcement using > existing networking tools like tc and iptables. By enabling net_cls cgroup it > gives mesos a more generalized way of allowing operators to enforce network > policy irrespective of whether the task is running in the global namespace or > in a specific network namespace. In other words it will allow network policy > enforcement to take place irrespective of the type of network isolator you > are using. For e.g., if someone wants to use ip-per-container (MESOS-2044) vs > the port mapping isolator, operators would still be able to perform policy > enforcement without relying on the network isolator to provide those > constructs. > > Cong Wang wrote: > True, I know what netcls is more than you do, but you just ignore the > fact that we _only_ have port mapping isolator in our _current_ code, that is > my whole point. We can always add this _after_ ip-per-container work is > merged in upstream, it is never too late. > > No need to mention this is hard to work together with the fq_codel > filters on egress. This is why I ask for more details, but you still don't > give any detail so far. > > Jie Yu wrote: > Cong, we already have other network isolators (e.g., Calico has one for > ip per container) through modules. I don't think the operator will allow two > network isolators to co-exists in production so I am not so worried about the > egress filter conflicts.
I know Calico is ip-per-container, but my point is Calico module is out-of-tree, why do we need this in tree just for an out-of-tree module? IOW, why not just let Calico carry this code? Also, you think the operator will not allow that, but you don't document it at all... - Cong ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/42047/#review114665 ----------------------------------------------------------- On Jan. 20, 2016, 5:05 a.m., Avinash sridharan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/42047/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2016, 5:05 a.m.) > > > Review request for mesos and Jie Yu. > > > Bugs: MESOS-4262 > https://issues.apache.org/jira/browse/MESOS-4262 > > > Repository: mesos > > > Description > ------- > > Specified the CgroupsNetClsIsolatorProcess class. This adds the ability to > isolate a mesos container using the net_cls cgroup subsystem. > > > Diffs > ----- > > src/CMakeLists.txt a52203ab9aa47315e6e5c58cc283a7b5df597c76 > src/Makefile.am 4fabe600d4ba38c95a777d622b0b675dd5811a53 > src/slave/containerizer/mesos/isolators/cgroups/net_cls.hpp PRE-CREATION > src/slave/containerizer/mesos/isolators/cgroups/net_cls.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/42047/diff/ > > > Testing > ------- > > > Thanks, > > Avinash sridharan > >
