[
https://issues.apache.org/jira/browse/MESOS-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14970790#comment-14970790
]
Alexander Rukletsov commented on MESOS-3765:
--------------------------------------------
This should work, but changes the current behaviour a bit. Let me reuse your
example to demonstrate how it works right now.
Two frameworks {{f1}} and {{f2}}, one agent with only 1 CPU. Possible scenarios:
* {{f1}} (or {{f2}}) receives 1 CPU, but accepts 0.5 CPU, effectively
returning 0.5 CPU to the free pool. {{f2}} is offered 0.5 CPU.
* {{f1}} (or {{f2}}) is greedy and accepts 1 CPU, rendering {{f2}} starve.
If a framework is a good citizen, it will accept only as much resources, as it
needs. At the same time, if a framework is good citizen, it won't lie about its
granularity. Hence I don't really see how having frameworks report their
preferable offer size can help to resolve allocation unfairness (which is
described in the ticket). I do not argue having frameworks' preferable offer
size allows for smarter allocation decisions and more efficient bin packing
algorithms, but this is out of the scope of the ticket.
My intuition is that *there is no way to improve fairness by giving frameworks
more tuning mechanism*. Having said that, I think tuning mechanism like
{{requestResources}} can be extremely useful.
Also, I think it can be difficult to deduce default granularity in presence of
multiple frameworks and varying agents.
> Make offer size adjustable (granularity)
> ----------------------------------------
>
> Key: MESOS-3765
> URL: https://issues.apache.org/jira/browse/MESOS-3765
> Project: Mesos
> Issue Type: Improvement
> Components: allocation
> Reporter: Alexander Rukletsov
>
> The built-in allocator performs "coarse-grained" allocation, meaning that it
> always allocates the entire remaining agent resources to a single framework.
> This may heavily impact allocation fairness in some cases, for example in
> presence of numerous greedy frameworks and a small number of powerful agents.
> A possible solution would be to allow operators explicitly specify
> granularity via allocator flags. While this can be tricky for non-standard
> resources, it's pretty straightforward for {{cpus}} and {{mem}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
