[
https://issues.apache.org/jira/browse/MESOS-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118870#comment-15118870
]
Guangya Liu commented on MESOS-4441:
------------------------------------
You can take a look at the review comments in
https://reviews.apache.org/r/42746/ and get your answer there.
--------------------Cited from [~jvanremoortere] feedback--------------------
The goal here is to introduce the "revocable by default" nature of offers
beyond quota. This is a nice opt-in mechanism as an operator currently has to
enable quota. We can treat this as a soft landing for "revocable by default".
In the future we will need revocation, as per reservation oversubscription
(a.k.a. optimistic offers), as well as to rebalance fairness as roles /
frameworks come and go.
Marking them as revocable also has the nice attribute that frameworks have to
explicitly acknowledge the revocable capability to go beyond their quota.
> Do not allocate non-revocable resources beyond quota guarantee.
> ---------------------------------------------------------------
>
> Key: MESOS-4441
> URL: https://issues.apache.org/jira/browse/MESOS-4441
> Project: Mesos
> Issue Type: Improvement
> Components: allocation
> Reporter: Alexander Rukletsov
> Assignee: Michael Park
> Priority: Blocker
> Labels: mesosphere
>
> h4. Status Quo
> Currently resources allocated to frameworks in a role with quota (aka
> quota'ed role) beyond quota guarantee are marked non-revocable. This impacts
> our flexibility for revoking them if we decide so in the future.
> h4. Proposal
> Once quota guarantee is satisfied we must not necessarily further allocate
> resources as non-revocable. Instead we can mark all offers resources beyond
> guarantee as revocable. When in the future {{RevocableInfo}} evolves
> frameworks will get additional information about "revocability" of the
> resource (i.e. allocation slack)
> h4. Caveats
> Though it seems like a simple change, it has several implications.
> h6. Fairness
> Currently the hierarchical allocator considers revocable resources as regular
> resources when doing fairness calculations. This may prevent frameworks
> getting non-revocable resources as part of their role's quota guarantee if
> they accept some revocable resources as well.
> Consider the following scenario. A single framework in a role with quota set
> to {{10}} CPUs is allocated {{10}} CPUs as non-revocable resources as part of
> its quota and additionally {{2}} revocable CPUs. Now a task using {{2}}
> non-revocable CPUs finishes and its resources are returned. Total allocation
> for the role is {{8}} non-revocable + {{2}} revocable. However, the role may
> not be offered additional {{2}} non-revocable since its total allocation
> satisfies quota.
> h6. Resource math
> If we allocate non-revocable resources as revocable, we should make sure we
> do accounting right: either we should update total agent resources and mark
> them as revocable as well, or bookkeep resources as non-revocable and convert
> them to revocable when necessary.
> h6. Coarse-grained nature of allocation
> The hierarchical allocator performs "coarse-grained" allocation, meaning it
> always allocates the entire remaining agent resources to a single framework.
> This may lead to over-allocating some resources as non-revocable beyond quota
> guarantee.
> h6. Quotas smaller than fair share
> If a quota set for a role is smaller than its fair share, it may reduce the
> amount of resources offered to this role, if frameworks in it do not accept
> revocable resources. This is probably the most important consequence of the
> proposed change. Operators may set quota to get guarantees, but may observe a
> decrease in amount of resources a role gets, which is not intuitive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
