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
