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

["Charles Allen (JIRA)" <ji...@apache.org>]

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

Charles Allen commented on MESOS-4697:
--------------------------------------

General feedback from someone who has written frameworks and deployed other frameworks.

Whenever I'm deploying a framework on Mesos, I rarely care about what isolation group it is using. Usually I simply want to have an understanding of how my resources are going to be requested/handled. This comes in play largely with frameworks who have different levels of resource awareness. Some know about memory and cpu, and a select few about disk needs.

As the capabilities of resource isolation expand, I do NOT want to have to go back and update older frameworks to make sure they play nice with more-modern frameworks with better resource awareness.

My current approach to handling this is through [roles | http://mesos.apache.org/documentation/latest/roles/] where a role is really a pre-agreed upon set of resource expectations.

What I would love to see is a way for me to have different cgroup roots per role. Or at least more clear expectations on how to have such a scenario. This way I can tune cgroups at a system level regardless of how aware mesos is of the node's capabilities.

As a discrete example, I would like to have blkio tuned on a node such that all tasks from a particular mesos role have some expectations of blkio, all tasks from a DIFFERENT mesos task have some other expectations, and a THIRD group of tasks which are NOT part of mesos might have a third set of tuningset. This could be accomplished within mesos IFF mesos were aware of all potential cgroups my kernel supports, AND all my frameworks had ways of running through mesos, but neither one of those is a guaranteed assumption.

My ask here is that the intended behavior is clarified for when a cgroup is present on a system, but the version of mesos running is not aware of how to use such a cgroup (blkio or maybe https://issues.apache.org/jira/browse/MESOS-4424 or something else even).

> 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
>
>
> 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([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|]). 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 by introduce a Subsystem abstraction. But we don't plan to support cgroup v2 in this ticket.



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