mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Bannier <benjamin.bann...@mesosphere.io>
Subject Re: Review Request 57254: Updated DRFSorter to support hierarchical roles.
Date Thu, 09 Mar 2017 18:06:34 GMT

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




src/master/allocator/mesos/hierarchical.hpp
Line 259 (original)
<https://reviews.apache.org/r/57254/#comment240738>

    Good this is gone as it was leaking sorter information.



src/master/allocator/mesos/hierarchical.cpp
Lines 1321-1348 (original), 1321-1329 (patched)
<https://reviews.apache.org/r/57254/#comment240737>

    This looks much nicer now.



src/master/allocator/sorter/drf/metrics.cpp
Line 62 (original), 62 (patched)
<https://reviews.apache.org/r/57254/#comment240739>

    It seems with some hierarchical `clientName` we would break the existing interface. We
should call this out when introducing the feature in the `CHANGELOG`.



src/master/allocator/sorter/drf/sorter.hpp
Lines 91 (patched)
<https://reviews.apache.org/r/57254/#comment240740>

    Let's not rely on the sentinel `end()` value, and instead return an `Option<Children::iterator>`.
    
        Option<Children::iterator> findChild(Client* child)
        {
          auto it = std::find(children.begin(), children.end(), child);
          return it != children.end() ? it : Option<Children::iterator>::none();
        }
        
    (this assumes a type aliases, but feel free to expand types
    
        using Children = std::set<Client*, DRFComparator>;
        
    )



src/master/allocator/sorter/drf/sorter.cpp
Line 72 (original), 112 (patched)
<https://reviews.apache.org/r/57254/#comment240741>

    Could we move the tree mutation here into `Client` or some other abstraction of the role
tree?



src/master/allocator/sorter/drf/sorter.cpp
Lines 233 (patched)
<https://reviews.apache.org/r/57254/#comment240742>

    This also looks like something which should be in a role tree abstraction.



src/master/allocator/sorter/sorter.hpp
Lines 74-76 (patched)
<https://reviews.apache.org/r/57254/#comment240736>

    Since this is a generic interface and a possible allocator modification point I don't
think we need to talk about `path` here (`client` seems just fine). I am also not sure we
need to here guarantee the side effects promised in the second sentence.
    
    What about just
    
        // Updates the weight of a client.
        virtual void updateWeight(const std::string& client, double weight) = 0;
    
    In principal we should also call out this change and the change to `add` in the `CHANGELOG`
as this is a public interface.


- Benjamin Bannier


On March 9, 2017, 5:44 p.m., Neil Conway wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57254/
> -----------------------------------------------------------
> 
> (Updated March 9, 2017, 5:44 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 646f66e67d9c6b8c61fc6e6558a1db976a44c126

>   src/master/allocator/mesos/hierarchical.cpp 0059ccead90f32491591990c791e7fa905a864b7

>   src/master/allocator/sorter/drf/metrics.hpp 61568cb520826ab59d675824b212e0d3deb63764

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

>   src/tests/master_allocator_tests.cpp 7b0b786f1c6c53616fd7ae1f7f765752d94a4f83 
>   src/tests/sorter_tests.cpp c93d236b13256f4022a811d019990ef81521aa77 
> 
> 
> Diff: https://reviews.apache.org/r/57254/diff/3/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Neil Conway
> 
>


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