----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/65106/#review195647 -----------------------------------------------------------
src/master/master.hpp Lines 2208 (patched) <https://reviews.apache.org/r/65106/#comment274911> can you use `CHECK_NE` here so that `task->state()` is auto printed when this fails? src/master/master.hpp Lines 2215 (patched) <https://reviews.apache.org/r/65106/#comment274910> s/the UI/in the UI/ src/master/master.hpp Lines 2334 (patched) <https://reviews.apache.org/r/65106/#comment274912> ditto. `CHECK_NE`? src/master/master.cpp Lines 10111-10127 (original), 10111-10119 (patched) <https://reviews.apache.org/r/65106/#comment275327> move this to #1061 Also, consider moving this to `protobuf_utils.hpp`. AFAICT this is used in 4 different places in this diff. src/master/master.cpp Lines 10247-10261 (original), 10245-10261 (patched) <https://reviews.apache.org/r/65106/#comment275332> Not yours, but I wish we can remove this if altogether and CHECK that we are only removing a terminal or unreachable task period. AFAICT, the only place where we violate this invariant is in `Master::finalize()`. Maybe add a TODO to fix? src/master/master.cpp Line 11423 (original), 11423 (patched) <https://reviews.apache.org/r/65106/#comment275333> CHECK_NE src/master/master.cpp Lines 11447 (patched) <https://reviews.apache.org/r/65106/#comment275336> Can you include taskid and frameworkid in the error message here for easy debuggability? - Vinod Kone On Jan. 12, 2018, 1:34 a.m., Benjamin Mahler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/65106/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2018, 1:34 a.m.) > > > Review request for mesos, James Peach, Vinod Kone, and Jiang Yan Xu. > > > Bugs: MESOS-8389 > https://issues.apache.org/jira/browse/MESOS-8389 > > > Repository: mesos > > > Description > ------- > > In the past, the notion of a "removable" task meant: the task is > terminal and acknowledged. However, the `isRemovable` helper only > defines removability by the task state (terminal or unreachable) > but not whether the terminal update is acknowledged. > > As a result, the code that is calling `isRemovable` is unintuitive. > One example of a confusing piece of code is within updateTask. Here, > we have logic which says, if the task is removable, recover the > resources but don't remove it. This seems more intuitive if directly > described as: "if the task is no longer consuming resources (e.g. > transitioned to terminal or unreachable) then recover the resources". > > If one looks up the documentation of `isRemovable`, it says "When a > task becomes removable, it is erased from the master's primary task > data structures", but that isn't accurate since this function doesn't > say whether the terminal task has been acknowledged, which is > required for a task to be removable. > > To make an immediate improvement, this patch removes `isRemovable` > (no pun intended) in favor of directly checking the states we care > about. In the future, we may want to introduce some helpers like > `isAllocatedResources` to describe whether the task's resources are > considered allocated. > > If we do introduce a notion of `isRemovable` in the future, it seems > it should take the `Task*` so that it can say whether the task could > be "removed" from the master, which includes checking that terminal > tasks have been acknowledged. However, "remove" is somewhat of a > confusing term, since what we're actually doing is "completing" the > task. > > > Diffs > ----- > > src/master/master.hpp 3d5180b8028b2a15ad111f91863e77747b362593 > src/master/master.cpp 465336d33008a848df063d4295416eb91f7bb44f > > > Diff: https://reviews.apache.org/r/65106/diff/2/ > > > Testing > ------- > > make check > > > Thanks, > > Benjamin Mahler > >
