----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66309/#review201449 -----------------------------------------------------------
src/resource_provider/registrar.hpp Line 67 (original), 69 (patched) <https://reviews.apache.org/r/66309/#comment282690> This comment seems not correct. src/resource_provider/registrar.hpp Line 69 (original), 71 (patched) <https://reviews.apache.org/r/66309/#comment282702> Does it make sense to use `process::Owned<state::Storage>&& storage`? src/resource_provider/registrar.hpp Lines 71-73 (original), 73-75 (patched) <https://reviews.apache.org/r/66309/#comment282701> I was wondering that, since we have a generic storage-backed registrar, could we also use this for the master's RP registrar and remove `MasterRegistrar`? - Chun-Hung Hsiao On April 10, 2018, 12:07 p.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/66309/ > ----------------------------------------------------------- > > (Updated April 10, 2018, 12:07 p.m.) > > > Review request for mesos, Jie Yu and Jan Schlicht. > > > Bugs: MESOS-8735 > https://issues.apache.org/jira/browse/MESOS-8735 > > > Repository: mesos > > > Description > ------- > > This patch changes the way the storage backing an agent's resource > provider registrar is created: while before we created it implicitly > when constructing the registrar, we now consume storage passed on > construction. > > Being able to explicitly inject the used storage simplifies testing. > > > Diffs > ----- > > src/resource_provider/registrar.hpp > 39f45b0a2a7c35bfe72a9305f5248409e4a3ef45 > src/resource_provider/registrar.cpp > 92ef9aecb1e93d10f46e53984391558f9901a60b > src/tests/resource_provider_manager_tests.cpp > c52541bf130ccf4795b989b53331176a64a097ea > > > Diff: https://reviews.apache.org/r/66309/diff/3/ > > > Testing > ------- > > `make check` > > > Thanks, > > Benjamin Bannier > >