[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.

["Ian Downes (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172285#comment-15172285 ] 

Ian Downes commented on MESOS-4697:
-----------------------------------

Those are valid reasons to consider changing the current code but can you talk more specifically about how a consolidated isolator would address, or deliberately not address, the original motivations? composability, extensibility, etc.

Can you confirm this would just be for isolation that manipulates cgroups? How would it be extensible? How would different functionality be selected, e.g., if there's a single cgroups isolator that includes net_cls but the operator did not want to enable, instead selecting something like the current network/port_mapping isolator? Could (1) not be addressed perhaps by composition with a generic cgroups isolator? and (2) could be addressed by fixing the existing somewhat rigid isolator <-> controller mapping while still preserving the separation of resource isolation, e.g., cpu and cpuacct naturally belong together. What hierarchy configuration(s) would the new isolator support? Would it be a new isolator or would it replace the existing isolators?

> Consolidate cgroup isolators into one single isolator.
> ------------------------------------------------------
>
>                 Key: MESOS-4697
>                 URL: https://issues.apache.org/jira/browse/MESOS-4697
>             Project: Mesos
>          Issue Type: Epic
>            Reporter: Jie Yu
>            Assignee: haosdent
>         Attachments: cgroup_v2.pdf
>
>
> Linux introduce the unified cgroup hierarchy since 3.16 [The unified control group hierarchy in 3.16|https://lwn.net/Articles/601840/], [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]
> There are two motivations for this:
> 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, mem, net_cls, etc.), many of the logics are the same. We are currently duplicating a lot of the code.
> 2) Initially, we decided to use a separate isolator for each cgroup subsystem is because we want each subsystem to be mounted under a different hierarchy. This gradually become not true with unified cgroup hierarchy introduced in kernel 3.16. Also, on some popular linux distributions, some subsystems are co-mounted within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It becomes very hard to co-manage a hierarchy by two isolators.
> We can still introduce subsystem specific code under the unified cgroup isolator (e.g., introduce a Subsystem abstraction?).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)