[
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)
