[
https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295040#comment-15295040
]
haosdent commented on MESOS-4697:
---------------------------------
Hi, [~drcrallen] Thank you very much for your nice feedbacks.
{quote}
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.
{quote}
Certainly we should not break anything for exists frameworks. This is confirmed
in our proposal. Framework developers also should not need to care about the
details about how Mesos isolate resources. All the frameworks need to do is to
implement the interfaces and call the APIs, then Mesos would choose the correct
way to satisfy or decline the requests.
{quote}
What I would love to see is a way for me to have different cgroup roots per
role.
{quote}
This make sense. Currently we create cgroup for every Mesos containers. Because
cgroup v1 allow user to create root hierarchies in different places, it is
tricky to implement it in current architecture(separate isolators for every
cgroup subsystem). It would become doable after we finish unified cgroup
isolator and support cgroup v2. And you may take a look at [QoS Isolator
Proposal |
https://docs.google.com/document/d/1peagt7dNgU78hQbjOz1fwPTs-ftYFP9DXAyetCM7XcY/edit#heading=h.sg28ikrbhimr]
as well. It could set different priorities for your frameworks instead of you
change cgroup configuration in every Mesos Agent.
{quote}
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
{quote}
In this case, Mesos could not isolate resources with those unsupported cgroup
subsystems until upgrade it.
> 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)
