> On March 7, 2019, 11 p.m., Benjamin Mahler wrote:
> > src/master/master.cpp
> > Lines 5919-5927 (original), 5924-5937 (patched)
> > <https://reviews.apache.org/r/70132/diff/2/?file=2129168#file2129168line5924>
> >
> >     I'm lost at what's happening here and why, can you add a guiding 
> > comment?

I added some more high-level comments explaining that we should implicitly 
decline unused but not converted resources. Is it now clear, or do you think I 
should add more explanations here?


- Chun-Hung


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/70132/#review213538
-----------------------------------------------------------


On March 8, 2019, 12:23 a.m., Chun-Hung Hsiao wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70132/
> -----------------------------------------------------------
> 
> (Updated March 8, 2019, 12:23 a.m.)
> 
> 
> Review request for mesos, Benjamin Mahler and Meng Zhu.
> 
> 
> Bugs: MESOS-9616
>     https://issues.apache.org/jira/browse/MESOS-9616
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Currently if a framework accepts an offer to perform pipelined
> operations, e.g., reserving resource, without a final consumer, the
> converted resources will be implicitly refused. This is an undesired
> behavior as the framework might want to reserve one resource first but
> launch a task later in the next allocation cycle. This patch fixes this
> behavior.
> 
> But, if the framework accepts an offers with multiple operations that
> cancel out each other, the resources consumed by these operations are
> still considered unused and will be refused.
> 
> 
> Diffs
> -----
> 
>   docs/scheduler-http-api.md 8384336bbecf2ca38a3cd203f9db28d931812d65 
>   src/master/master.cpp b9db4ffd4ee8ea4a8e44a35d1afb6c1b8e03d74d 
>   src/tests/slave_tests.cpp 5ee5609af0861e9aecf02a5eaefafe137bd9b843 
> 
> 
> Diff: https://reviews.apache.org/r/70132/diff/3/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Chun-Hung Hsiao
> 
>

Reply via email to