[ 
https://issues.apache.org/jira/browse/MESOS-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101838#comment-15101838
 ] 

Guangya Liu edited comment on MESOS-4392 at 1/15/16 2:53 PM:
-------------------------------------------------------------

Just some early questions, so seems we want to do the things to enable Quoted 
resources can be lend out to other roles if framework on current role is idle.

There is a problem for this: The current Quota logic only define the {{Quota 
Guaranteed}} resources which we can treat it as {{Minimum ownership}} of one 
role and I know that we have plan to introduce {{Quota Limit}} which can define 
kind of {{Maximum ownership}} resources reserved by a role. I think that we 
should ONLY treat the resources between {{Quota Limit}} and {{Quota 
Guaranteed}} as quota revocable resources. 

The admin can define a small {{Quota Guaranteed}} if s/he do not want to waste 
too much resources in case of idle frameworks, then the resources between 
{{Quota Limit}} and {{Quota Guaranteed}} can be treated as revocable resources 
and lend out to other frameworks.

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.


was (Author: gyliu):
Just some early questions, so seems we want to do the things to enable Quoted 
resources can be lend out to other roles if framework on current role is idle.

There is a problem for this: The current Quota logic only define the {{Quota 
Guaranteed}} resources which we can treat it as {{Minimum ownership}} of one 
role and I know that we have plan to introduce {{Quota Limit}} which can define 
kind of {{Maximum ownership}} resources reserved by a role. I think that we 
should ONLY treat the resources between {{Quota Limit}} and {{Quota 
Guaranteed}} as quota revocable resources. 

The admin can define a small {{Quota Guaranteed}} if s/he do not want to waste 
too much resources in case of idle frameworks, then the resources between 
{{Quota Limit}} and {{Quota Guaranteed}} can be treated as revocable resources 
and lend out to other frameworks.

With this solution, seems the {{Quota Limit}} does not make much sense: The 
admin can set a large {{Quota Guaranteed}} and lend out its resources to other 
frameworks.

> 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)

Reply via email to