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 takes
(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 support the following
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 an
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 resi
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
