[
https://issues.apache.org/jira/browse/MESOS-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14552772#comment-14552772
]
Joris Van Remoortere commented on MESOS-2652:
---------------------------------------------
[~idownes][~vinodkone] I chatted with [~nnielsen] about the weird behavior if
an executor that is *intended to be BE* is first started with purely
non-revocable resources to start (due to the revocable resource it is
interested in not being available currently).
My thought was to be more explicit when an executor starts up that it is
intended to be BE. This way we are not **guessing** about how we should be
isolating this container. I agree with [~nnielsen] that we should still fail
hard if we try to add revocable resources to a PR executor. I think being
explicit about the executor (as well as the resources) reduces the surface
areas for bugs and hard to diagnose isolation issues.
Thoughts?
> Update Mesos containerizer to understand revocable cpu resources
> ----------------------------------------------------------------
>
> Key: MESOS-2652
> URL: https://issues.apache.org/jira/browse/MESOS-2652
> Project: Mesos
> Issue Type: Task
> Reporter: Vinod Kone
> Assignee: Ian Downes
> Labels: twitter
>
> The CPU isolator needs to properly set limits for revocable and non-revocable
> containers.
> The proposed strategy is to use a two-way split of the cpu cgroup hierarchy
> -- normal (non-revocable) and low priority (revocable) subtrees -- and to use
> a biased split of CFS cpu.shares across the subtrees, e.g., a 20:1 split
> (TBD). Containers would be present in only one of the subtrees. CFS quotas
> will *not* be set on subtree roots, only cpu.shares. Each container would set
> CFS quota and shares as done currently.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
