[
https://issues.apache.org/jira/browse/MESOS-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106119#comment-15106119
]
Klaus Ma commented on MESOS-4392:
---------------------------------
For this ticket, I think we're going to only handle "unused part of the quota".
For the {{Quota Slack}}, I think there're so many "slack" in Mesos now: usage
slack, allocation slack and quota slack if done; but we still can not cover all
un-reserved resources.
As I mentioned in "https://reviews.apache.org/r/41772/#comment173654";, I'd like
a MVP worked with Quota to cover all un-reserved resources:
1. For this ticket, it cover the un-used unreserved resources within
{{Quota Guarantee}}
2. For the new MVP, it share unreserved resources beyond {{Quota
Guarantee}} based on {{Quota Ratio}} by {{DRF}}; according to {{DRF}}, the
deserved part are offered as normal, the other resources are offered as
revocable.
#2 is also first part of MESOS-4303 I'm thinking recently :).
> Balance quota frameworks with non-quota, greedy frameworks.
> -----------------------------------------------------------
>
> Key: MESOS-4392
> URL: https://issues.apache.org/jira/browse/MESOS-4392
> Project: Mesos
> Issue Type: Epic
> Components: allocation, master
> Reporter: Bernd Mathiske
> Assignee: Alexander Rukletsov
> Labels: mesosphere
>
> Maximize resource utilization and minimize starvation risk for both quota
> frameworks and non-quota, greedy frameworks when competing with each other.
> A greedy analytics batch system wants to use as much of the cluster as
> possible to maximize computational throughput. When a competing web service
> with fixed task size starts up, there must be sufficient resources to run it
> immediately. The operator can reserve these resources by setting quota.
> However, if these resources are kept idle until the service is in use, this
> is wasteful from the analytics job's point of view. On the other hand, the
> analytics job should hand back reserved resources to the service when needed
> to avoid starvation of the latter.
> We can assume that often, the resources needed by the service will be of the
> non-revocable variety. Here we need to introduce clearer distinctions between
> oversubscribed and revocable resources that are not oversubscribed. An
> oversubscribed resource cannot be converted into a non-revocable resource,
> not even by preemption. In contrast, a non-oversubscribed, revocable resource
> can be converted into a non-revocable resource.
> Another related topic is optimistic offers. The pertinent aspect in this
> context is again whether resources are oversubscribed or not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
