[
https://issues.apache.org/jira/browse/MESOS-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105066#comment-15105066
]
Bernd Mathiske commented on MESOS-4392:
---------------------------------------
Yes, I should clarify what I am trying to suggest here. Revoking a SINGLE
accepted oversubscription offer for a resource cannot make the resource
non-revocable, because another task may be holding on to its actual physical
assets. Only revoking the "regular" offer that claims the same resource would
create a clear enough picture to assign the resource as non-revocable to a new
primary "owner". We'd then rely on the QoS mechanism to satisfy the needs of
the latter in case a third, revocable offer were currently using the resource.
It is unclear to me from this doc whether oversubscription can only occur when
there is also one "regular" offer for the same resource:
https://github.com/nqn/mesos/blob/niklas/oversubscription-user-doc/docs/oversubscription.md
My guess would be that you can also have revocable resources only and still
achieve oversubscription. In any case, once we make revocable the default this
will be the case. Then the situation above will change slightly. Not having a
goto "regular owner" offer that determines whether the resource is actually
available, we can immediately hand out a non-revokable offer. QoS should then
make the physical resource available on demand. Alternatively, maybe as a
booster option to speed things up, we could provide a clean slate by revoking
the entire oversubscription set.
> 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)
