mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chun-Hung Hsiao <chhs...@apache.org>
Subject Re: Review Request 70132: Do not implicitly decline speculatively converted resources.
Date Tue, 23 Apr 2019 15:50:14 GMT


> 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message