> On March 10, 2017, 1:41 a.m., Michael Park wrote: > > src/master/allocator/sorter/drf/metrics.hpp > > Lines 44-45 (original), 44-45 (patched) > > <https://reviews.apache.org/r/57254/diff/3/?file=1660317#file1660317line44> > > > > (1) Can we pull the changes to `metrics` out to a separate patch? For > > example, we could first have a patch that changes the signatures of > > `Sorter::find` and `Sorter::calculateShare` (unrelated to the hierarchy > > changes). > > (2) Do we need this renaming at the API level? If yes, shouldn't this > > be consistent for all functions that take `const std::string& client` > > currently?
Reverted the renaming in metrics. I don't think pulling the `DRFSorter::find` change out into a separate review would be useful, because returning a `Client*` from `find()` only makes sense if we're storing `Client*` in the first place (which is only introduced by the hierarchy changes). - Neil ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/57254/#review168554 ----------------------------------------------------------- On March 10, 2017, 6:11 p.m., Neil Conway wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/57254/ > ----------------------------------------------------------- > > (Updated March 10, 2017, 6:11 p.m.) > > > Review request for mesos, Benjamin Bannier, Benjamin Mahler, and Michael Park. > > > Repository: mesos > > > Description > ------- > > This commit replaces the sorter's flat list of clients with a tree of > client names; this tree represents the hierarchical relationship between > sorter clients. Each node in the tree contains an (ordered) list of > pointers to child nodes. The tree might contain nodes that do not > correspond directly to sorter clients. For example, adding clients "a/b" > and "c/d" results in the following tree: > > root > -> a > -> b > -> c > -> d > > The `sort` member function still only returns one result for each > (active) client in the sorter. This is implemented by ensuring that each > sorter client is associated with a leaf node in the tree. Note that it > is possible for a leaf node to be transformed into an internal node by a > subsequent insertion; to handle this case, we "implicitly" create an > extra child node, which maintains the invariant that each client has a > leaf node. For example, if the client "a/b/x" is added to the tree > above, the result is: > > root > -> a > -> b > -> . > -> x > -> c > -> d > > The "." leaf node holds the allocation that has been made to the "a/b" > client itself; the "a/b" node holds the sum of all the allocations that > have been made to the subtree rooted at "a/b", which also includes > "a/b/x". > > > Diffs > ----- > > src/master/allocator/mesos/hierarchical.hpp > f84b0574ce9a392c9528c87b04b01dbb2053cff7 > src/master/allocator/mesos/hierarchical.cpp > 37fb7a62ef95c2f6e5a9e9a4ab49260332e2b03b > src/master/allocator/sorter/drf/metrics.cpp > 15aab32db5ca1a7a14080e9bbb7c65283be3ec20 > src/master/allocator/sorter/drf/sorter.hpp > 76329220e1115c1de7810fb69b943c78c078be59 > src/master/allocator/sorter/drf/sorter.cpp > ed54680cecb637931fc344fbcf8fd3b14cc24295 > src/master/allocator/sorter/sorter.hpp > b3029fcf7342406955760da53f1ae736769f308c > src/tests/hierarchical_allocator_tests.cpp > dce619ec49db480685deb1bf8f7faeebe02e25b5 > src/tests/master_allocator_tests.cpp > 0fb66e4255a71e9082f99a8bd202aec691a06939 > src/tests/sorter_tests.cpp ec0636beb936d46a253d19322f2157abe95156b6 > > > Diff: https://reviews.apache.org/r/57254/diff/4/ > > > Testing > ------- > > > Thanks, > > Neil Conway > >
