----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33159/#review84893 -----------------------------------------------------------
src/master/allocator/mesos/hierarchical.hpp <https://reviews.apache.org/r/33159/#comment136338> According to this comment, I assume that now we do not allow frameworks to re-register with a new role or checkpoint flag. If this is the case, does it make sense to verify and therefore document these assumptions? Something like ``` CHECK(frameworks[frameworkId].role == frameworkInfo.role()) ``` Without this, the patch looks like harness code for future changes. On the same page, we do allow some of the `FrameworkInfo`'s fields to change on the re-registration. IIRC, they are all irrelevant to allocation, but do you mind throwing a comment about that? - Alexander Rukletsov On April 20, 2015, 6:46 p.m., Joris Van Remoortere wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/33159/ > ----------------------------------------------------------- > > (Updated April 20, 2015, 6:46 p.m.) > > > Review request for mesos and Benjamin Hindman. > > > Bugs: MESOS-2615 and MESOS-703 > https://issues.apache.org/jira/browse/MESOS-2615 > https://issues.apache.org/jira/browse/MESOS-703 > > > Repository: mesos > > > Description > ------- > > Follow up of 32961 where we add the 'updateFramework' function to the > allocator. > > > Diffs > ----- > > src/master/allocator/allocator.hpp 91f80501aa9bc733fd53f9cb1ac0f15949a74964 > src/master/allocator/mesos/allocator.hpp > fb898f1175b61b442204e6e38c69ccc2838a646f > src/master/allocator/mesos/hierarchical.hpp > 9f9a631ee52a3ab194e678f9be139e8dabc7f3db > src/master/master.cpp 44b0a0147f5354824d86332a67b30018634c9a36 > src/tests/mesos.hpp 42e42ac425a448fcc5e93db1cef1112cbf5e67c4 > > Diff: https://reviews.apache.org/r/33159/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Joris Van Remoortere > >
