Re: RFC: RevocableInfo Changes

Answer inline :). > On Mar 29, 2016, at 05:25, Niklas Nielsen wrote: > > Echoing Ben Mahler's comment. I still don't find the ThrottleInfo very > intuitive. [Klaus]: Not sure which one is better: "ScavengeInfo"/ "BestEffortInfo"/“ThrottleableInfo” :). > Did you discuss the

Re: RFC: RevocableInfo Changes

Echoing Ben Mahler's comment. I still don't find the ThrottleInfo very intuitive. Did you discuss the general notion of resource quality further? On Mon, Mar 21, 2016 at 11:50 PM, Klaus Ma wrote: > @benm/joris, > > here's the user scenario in my mind: > > 1. master

Re: RFC: RevocableInfo Changes

@benm/joris, here's the user scenario in my mind: 1. master offers resources to the framework, e.g. 2 cpu 2. framework launch a task (2 cpu) and *mark the task/executors as throttleable* 3. in ResourceEstimator, it should only consider the throttleable task/executors: - keep enough resources

Re: RFC: RevocableInfo Changes

Some of my thinking here: 1) The ThrottleInfo may need to belong to "Resources" but not limited to "RevocableInfo". The cpus resources can be throttled even if it is not revocable resources. 2) There need to be a flag to indicate if the resources is Scavenge-able or Best effort, I did not have

Re: RFC: RevocableInfo Changes

Yeah that's definitely a question I've been asking myself, and we synced on that with Niklas during the last meeting. The thought currently is that we should choose a better name than ThrottleInfo. ThrottleInfo seems to carry too strong of an implication about what the resources will experience.

Re: RFC: RevocableInfo Changes

@klaus: I think @connor's question is whether we are absolutely sure we never want to support throttle-able but non-revocable resources. It's clear from the protos that this is not supported, the question is whether we are sure that is what we want. If so, can you elaborate as to *why* we would

Re: RFC: RevocableInfo Changes

Here's some input :). If throttling is tolerable but preemption is not, how would that be expressed? (Is that supported?) [Klaus]: It's not supported; only revocable resources has this attribute: non-throttleable or throttleable. The throttleable revocable resources is reported by

Re: RFC: RevocableInfo Changes

Thanks for the good explanations so far Ben and Klaus. Apologies if you guys already covered these questions in the meeting: If throttling is tolerable but preemption is not, how would that be expressed? (Is that supported?) How does this work with the QoS controller? Will there be a new

Re: RFC: RevocableInfo Changes

Also please show your comments if any for the name here, the current name is *ThrottleInfo*, in Kubernetes resources qos design document, they are using scavenging as the key work for such behaviour, so a possible name here could be *ScavengeInfo , *please show your comments if any for those

Re: RFC: RevocableInfo Changes

@team, in the latest meeting, we agree to keep current name *ThrottleInfo.* If any more comments, please let me know. On Wednesday, March 16, 2016 at 9:32:37 PM UTC+8, Guangya Liu wrote: > > Also please show your comments if any for the name here, the current name > is *ThrottleInfo*, in

Re: RFC: RevocableInfo Changes

The patches are updated accordingly; JIRA: 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

Re: RFC: RevocableInfo Changes

@ Niklas/Jie, just sent the invitation to you :) Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer Platform OpenSource Technology, STG, IBM GCG +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me On Tue, Mar 15, 2016 at 10:06 AM, Guangya Liu wrote: > This

Re: RFC: RevocableInfo Changes

This is the google doc that we used to trace all discussion topics: https://docs.google.com/document/d/1B_v52zCOFcwCpqCPhgYi9h630a0NE-QM9Br0nCOZUR4/edit?usp=sharing This is the link for google hang out video call Join video call

Re: RFC: RevocableInfo Changes

Sounds good, the next one is tomorrow March 15th at 5pm PST (they are at 5pm PST to accommodate China time zone). Will that work? On Mon, Mar 14, 2016 at 10:53 AM, Niklas Nielsen wrote: > Ben, when do you have your next mesos allocator sync? We don't have our > next performance

Re: RFC: RevocableInfo Changes

Ben, when do you have your next mesos allocator sync? We don't have our next performance isolation sync lined up yet, so we could piggy back on yours if you have it scheduled already. Niklas On Mon, Mar 14, 2016 at 9:32 AM, Jie Yu wrote: > > > > Just a quick note: Ian D.

Re: RFC: RevocableInfo Changes

> > Just a quick note: Ian D. and the performance isolation working group are > discussing similar annotations and we should meet and talk about the > options. +1 Would love to understand the relationship between this and the task/executor level annotations. - Jie On Mon, Mar 14, 2016 at 9:29

Re: RFC: RevocableInfo Changes

Hi Ben, Just a quick note: Ian D. and the performance isolation working group are discussing similar annotations and we should meet and talk about the options. Niklas On Sat, Mar 12, 2016 at 12:05 AM, Klaus Ma wrote: > Yes, I think that's true for now; so we define

Re: RFC: RevocableInfo Changes

Yes, I think that's true for now; so we define `ThrottleInfo` as message to be more flexible. In Optimistic Offer Phase 1, we only use it to distinguish usage oversubscriptions and allocation oversubscription, similar to bool :). Regarding the resources type, two questions after the discussion:

Re: RFC: RevocableInfo Changes

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

RFC: RevocableInfo Changes

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