mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Conway <neil.con...@gmail.com>
Subject Re: Review Request 57254: Updated DRFSorter to support hierarchical roles.
Date Sat, 11 Mar 2017 01:35:37 GMT


> 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message