Hi Ben,
I think that currently and even in the near future, the __ThrottleInfo__
will only be used by the usage oversubscriptions and the oversubscription
for allocator (Both quota and reservations) will not use this value but
only using __RevocableInfo__ is enough.
I can even think that the __ThrottleInfo__ as a boolean value in optimistic
offer phase 1 as it is mainly used to distinguish resources between usage
oversubscriptions and allocation oversubscription (Quota and Reservations),
comments?
Thanks,
Guangya
在 2016年3月12日星期六 UTC+8上午11:09:46，Benjamin Mahler写道：
>
> Hey folks,
>
> In the resource allocation working group we've been looking into a few
> projects that will make the allocator able to offer out resources as
> revocable. For example:
>
> -We'll want to eventually allocate resources as revocable _by default_,
> only allowing non-revocable when there are guarantees put in place (static
> reservations or quota).
>
> -On the path to revocable by default, we can incrementally start to offer
> certain resources as revocable. Consider when quota is set but the role
> isn't using all of the quota. The unallocated quota can be offered to other
> roles, but it should be revocable because we may revoke them should the
> quota'ed role want to use the resources. Unused reservations fall into a
> similar category.
>
> -Going revocable by default also allows us to enforce fairness in a
> dynamically changing cluster by revoking resources as weights are changed,
> frameworks are added or removed, etc.
>
> In this context, "revocable" means that the resources may be taken away
> and the container will be destroyed. The meaning of "revocable" in the
> context of usage oversubscription includes this, but also the container may
> experience a throttling (e.g. lower cpu shares, less network priority, etc).
>
> For this reason, and because we internally need to distinguish revocable
> resources between the those that are generated by usage oversubscription
> and those that are generated by the allocator, we're thinking of the
> following change to the API:
>
>
>
> - message RevocableInfo {}
> + message RevocableInfo {
> + message ThrottleInfo {}
> +
> + // If set, indicates that the resources may be throttled at
> + // any time. Throttle-able resoruces can be used for tasks
> + // that do not have strict performance requirements and are
> + // capable of handling being throttled.
> + optional ThrottleInfo throttle_info;
> + }
>
> // If this is set, the resources are revocable, i.e., any tasks or
> - // executors launched using these resources could get preempted or
> - // throttled at any time. This could be used by frameworks to run
> - // best effort tasks that do not need strict uptime or performance
> + // executors launched using these resources could be terminated at
> + // any time. This could be used by frameworks to run
> + // best effort tasks that do not need strict uptime
> // guarantees. Note that if this is set, 'disk' or 'reservation'
> // cannot be set.
> optional RevocableInfo revocable = 9;
>
>
>
> Essentially we want to distinguish between revocable and revocable +
> throttle-able. This is because usage-oversubscription generates
> throttle-able revocable resources, whereas the allocator does not. This
> also solves our problem of distinguishing between these two kinds of
> revocable resources internally.
>
> Feedback welcome!
>
> Ben
>
>
