The patches are updated accordingly; JIRA: MESOS-3888 <https://issues.apache.org/jira/browse/MESOS-3888> , RR: https://reviews.apache.org/r/40375/ .
Thanks klaus On Saturday, March 12, 2016 at 11:09:46 AM UTC+8, Benjamin Mahler wrote: > > 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 > >