> On April 23, 2019, 10:47 a.m., Benjamin Bannier wrote: > > docs/scheduler-http-api.md > > Line 132 (original), 132 (patched) > > <https://reviews.apache.org/r/70132/diff/5/?file=2140649#file2140649line132> > > > > What do you think of getting rid of "implicitly declined" behavior for > > "cancelling operations"? > > > > It seems that behavior is more driven by the implementation than > > intuitive api behavior; it e.g., forces frameworks to reason differently > > about operations executed in isolation vs. executed together. It seems > > having the identical behavior for both cases would both be easier to > > explain and also program against. The behavior that seems to make most > > sense for me would be to only ever implictly decline "untouched resources", > > e.g., if accepting offered `cpus:4` with `RESERVE(cpus:2, role) && > > UNRESERVE(cpus:2, role)` we would implicitly decline only `cpus:2`.
It seems to me that "cancelling operations" as something that are both 1. very rare and 2. make little sense for frameworks, so I'm more like delivering a fix for common cases without making the alrealy-messy code path more complicated. WDYT? Also @bmahler what's your opinion on @bbannier's suggestion? IIRC you mentioned something like some are designed behaviors before, but I didn't know the context. > On April 23, 2019, 10:47 a.m., Benjamin Bannier wrote: > > src/master/master.cpp > > Lines 5963-5964 (original), 5983-5984 (patched) > > <https://reviews.apache.org/r/70132/diff/5/?file=2140650#file2140650line5983> > > > > Is this a workaround we need until MESOS-4553 gets resolved? If it is, > > let's add a `TODO`. I don't know actually lol. I just copied it from https://github.com/apache/mesos/blob/45c9788618e7123f408a1dffcf6772a1285cd2e5/src/master/master.cpp#L10969-L10972, as @mzhu suggested that if there's an allocation in between there might be offer fragmentation. Is this a workaround for MESOS-4553? > On April 23, 2019, 10:47 a.m., Benjamin Bannier wrote: > > src/tests/slave_tests.cpp > > Lines 6499 (patched) > > <https://reviews.apache.org/r/70132/diff/5/?file=2140651#file2140651line6499> > > > > Since the changes in this patch are strongly related to behavior > > framework authors need to reason about I strongly feel that we must add a > > test for the expected behavior. I could add a unit test in a separated patch. This patch itself will be backported, after discussed with @bmahler. - Chun-Hung ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/70132/#review214812 ----------------------------------------------------------- On April 23, 2019, 1:15 a.m., Chun-Hung Hsiao wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/70132/ > ----------------------------------------------------------- > > (Updated April 23, 2019, 1:15 a.m.) > > > Review request for mesos, Benjamin Bannier, 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 declined. 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 declined. > > > Diffs > ----- > > docs/scheduler-http-api.md a5327c229142267836f327f9c382ef50b7e334db > src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 > src/tests/slave_tests.cpp b1c3a01031b917fb9773c8c890a8f88838870559 > > > Diff: https://reviews.apache.org/r/70132/diff/5/ > > > Testing > ------- > > make check > > > Thanks, > > Chun-Hung Hsiao > >
