----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/57254/#review168982 -----------------------------------------------------------
Per design doc, we always associate framework to a virtual role. In this implementation, however, virtual role is created ONLY when the leaf node is turned into internal node. Could you clarify a bit? src/master/allocator/sorter/drf/sorter.cpp Lines 101 (patched) <https://reviews.apache.org/r/57254/#comment241319> It would be nice to add some comments here to help reader understand that we are traversing the tree using each element of `roles`, in order to position it in the tree, much like what `mkdir -p /path/to/create/dir` would do. - Jay Guo On March 14, 2017, 1:59 p.m., Neil Conway wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/57254/ > ----------------------------------------------------------- > > (Updated March 14, 2017, 1:59 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/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 > 9f3750215f2b72f6148d0c47cdde6a3f7dfb1b50 > src/tests/sorter_tests.cpp ec0636beb936d46a253d19322f2157abe95156b6 > > > Diff: https://reviews.apache.org/r/57254/diff/9/ > > > Testing > ------- > > > Thanks, > > Neil Conway > >
