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 Mon, 13 Mar 2017 18:06:14 GMT


> On March 10, 2017, 1:41 a.m., Michael Park wrote:
> > src/master/allocator/sorter/drf/sorter.hpp
> > Lines 68-70 (patched)
> > <https://reviews.apache.org/r/57254/diff/3/?file=1660319#file1660319line68>
> >
> >     It seems like changing the behavior around the members of the `clients` map,
as it simply gets marked as inactive rather than removed from the map. Is it possible to make
this change before we introduce the role hierarchy?

Note that this doesn't actually change observable behavior. But yeah, I split this change
into a separate RR.


- Neil


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57254/#review168554
-----------------------------------------------------------


On March 13, 2017, 6:04 p.m., Neil Conway wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57254/
> -----------------------------------------------------------
> 
> (Updated March 13, 2017, 6:04 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 0fb66e4255a71e9082f99a8bd202aec691a06939 
>   src/tests/sorter_tests.cpp ec0636beb936d46a253d19322f2157abe95156b6 
> 
> 
> Diff: https://reviews.apache.org/r/57254/diff/7/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Neil Conway
> 
>


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