[
https://issues.apache.org/jira/browse/MESOS-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106093#comment-15106093
]
Guangya Liu commented on MESOS-4392:
------------------------------------
When we do the design for Optimistic offer phase 1 (MESOS-1607), we already
considered this case, we can call this as {{Quota Slack}} which means the
difference between the amount of {{quotaed resources}} and the amount of
{{allocated resources}}.
But before we proceed for this, I think that we need to consider how does the
{{Quota Slack}} works if we introduced {{Quota Limit}}, at least need to
clarify in the design document for this.
{quota}
With this solution, seems the Quota Limit does not make much sense: The admin
can set a large Quota Guaranteed and lend out current role's resources to other
roles.
{quota}
Personally, for an ideal design, if we have both {{Quota Guarantee}} and
{{Quota Limit}}, we should document to tell end user guarantee less resources
and make the resources between {{Quota Guarantee}} and {{Quota Limit}} as
revocable which is the {{Quota Slack}} in my thinking.
> 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)
