Re: Please review design doc for task resizing

Since we all agree option 2 is the best option for scheduler API's change, I have updated design doc by marking it as the first option which means it is the final decision. I see. However, that operation is not idempotent. Imagine you issue a > resize request and for some reason, the request

Re: Please review design doc for task resizing

(Inlined) On Mon, Dec 7, 2015 at 6:54 AM, Qian Zhang wrote: > Thanks Niklas for your comments :-) > > For your first comment, so you prefer option 2 in the design doc (i.e., add > resize as a new offer operation), right? Actually after more thinking, I > think if we want to

Re: Please review design doc for task resizing

Thanks Niklas for your comments :-) For your first comment, so you prefer option 2 in the design doc (i.e., add resize as a new offer operation), right? Actually after more thinking, I think if we want to support the following 2 use cases (especially the second one) and OK to resize a task with

Re: Please review design doc for task resizing

Hi Qian, Thanks for the update and I apologize the response time. Do you have a PoC implementation of your proposal? I have trouble understanding the motivation of _not_ adding resizing as a usual operation. It seems much cleaner in my mind. To David G's and Alex R's comment: if you want to

Please review design doc for task resizing

Hi All, I am currently working on task resizing (MESOS-938), and have drafted a design doc (see the link below). https://docs.google.com/document/d/15rVmS2AXLzTDSEugAVDxWuHFUentp82KhL2yzxBCsi8/edit?usp=sharing Please feel free to review it, any comments are welcome, thanks! Regards, Qian