[
https://issues.apache.org/jira/browse/MESOS-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15108617#comment-15108617
]
Guangya Liu commented on MESOS-4441:
------------------------------------
Can I summary what you want to do as this?
1) Allocate quota first with unreserved non revocable in stage 1, if quota is
satisfied. goto 2), else goto 3).
2) Allocate revocable resources only in stage 2.
3) Allocate both reserved and revocable resources in stage 2.
One problem is that this may cause some resources wasted, one example is that
one host has "cpus(*):100" and a role quota is "cpus(*):40", then if a
framework register with this role, the role can get its quota but the left 60
cpu will not be allocated as it is not revocable, this will waste those 60 cpus
resources.
> 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: Alexander Rukletsov
> 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. 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)
