----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/69337/#review211313 -----------------------------------------------------------
src/master/master.cpp Lines 8205 (patched) <https://reviews.apache.org/r/69337/#comment296301> How about making this if-statement include the RP update logic above, calculating the set of received resource providers in the foreach loop, and put the GC logic after that loop, so the whole update looks more cohesive? src/master/master.cpp Lines 8225-8230 (patched) <https://reviews.apache.org/r/69337/#comment296302> Can we simply do the following, i.e., is `slave->totalResources` always in sync with `slave->resourcesProviders.at(resourcePRoviderId).totalResources`? ``` slave->totalResources -= slave->resourceProviders.at(resourceProviderId).totalResources; ``` - Chun-Hung Hsiao On Dec. 13, 2018, 1:51 p.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/69337/ > ----------------------------------------------------------- > > (Updated Dec. 13, 2018, 1:51 p.m.) > > > Review request for mesos, Chun-Hung Hsiao and Jan Schlicht. > > > Bugs: MESOS-9384 > https://issues.apache.org/jira/browse/MESOS-9384 > > > Repository: mesos > > > Description > ------- > > The master previously kept information on resource providers > indefinitely. This was confusing to API users who saw resource > providers reported which where not present anymore, and also made it > harder to derive actual cluster state. > > With this patch we remove resource providers not reported by the agent > from master state. We still need to update the agent to not report > removed resource providers in a follow-up patch. > > > Diffs > ----- > > src/master/master.cpp 3de0fd35cc815f4b5787ee2cb5e81f5059d7a47c > > > Diff: https://reviews.apache.org/r/69337/diff/2/ > > > Testing > ------- > > `make check` > > > Thanks, > > Benjamin Bannier > >
