mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Mahler <bmah...@apache.org>
Subject Re: Review Request 64003: Made quota resource allocation fine-grained.
Date Tue, 19 Dec 2017 03:27:51 GMT

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




src/master/allocator/mesos/hierarchical.cpp
Line 1750 (original), 1797 (patched)
<https://reviews.apache.org/r/64003/#comment272836>

    limits



src/master/allocator/mesos/hierarchical.cpp
Line 1751 (original), 1798 (patched)
<https://reviews.apache.org/r/64003/#comment272835>

    I think this patch also needs to update the quota satisfaction criteria now that we can
chop. Breaking when only a single guarantee is reached was meant as a stop-gap for the gaming
ticket reference on `someGuaranteesReached`. Now we could move back to considering quota satisfied
only when all of the guarantees are reached.



src/master/allocator/mesos/hierarchical.cpp
Line 1752 (original), 1799 (patched)
<https://reviews.apache.org/r/64003/#comment272840>

    Maybe: These are all scalar quantities



src/master/allocator/mesos/hierarchical.cpp
Lines 1800 (patched)
<https://reviews.apache.org/r/64003/#comment272841>

    Maybe `unsatisfiedQuota`?



src/master/allocator/mesos/hierarchical.cpp
Lines 1803 (patched)
<https://reviews.apache.org/r/64003/#comment272842>

    Do we need a note here to clarify why we don't care to use `allocatableTo(role)`?
    
    ```
    // Note that since we currently only support top-level roles to
    // have quota, there are no ancestor reservations involved here.
    ```



src/master/allocator/mesos/hierarchical.cpp
Lines 1806-1814 (patched)
<https://reviews.apache.org/r/64003/#comment272845>

    The more important distinction for the reader here seems to be the resources that have
a limit and those that don't?
    
    (1) resources w/ limit: always choppable, chop up to limit
    
    (2) resources w/o limit: offer entirely, may or may not be choppable but we don't care..?
    
    I think with the current logic here, if I don't have quota limit for "some-scalar", because
it's choppable it will get excluded during the intersection and I won't get it offered?
    
    Also, as discussed offline, this is missing metadata?


- Benjamin Mahler


On Dec. 12, 2017, 2:33 a.m., Meng Zhu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/64003/
> -----------------------------------------------------------
> 
> (Updated Dec. 12, 2017, 2:33 a.m.)
> 
> 
> Review request for mesos, Benjamin Mahler and Michael Park.
> 
> 
> Bugs: MESOS-7099
>     https://issues.apache.org/jira/browse/MESOS-7099
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Allocator now does fine-grained resource allocation up
> to the role’s quota limit.
> 
> Also fixed a few affected allocator tests.
> 
> 
> Diffs
> -----
> 
>   src/master/allocator/mesos/hierarchical.cpp fccd71c96fe8e4d914e19b5ea8d8f69e9ebf2406

>   src/tests/hierarchical_allocator_tests.cpp f5fb47ed09682ebdd047aec7e79a86597ee09f53

> 
> 
> Diff: https://reviews.apache.org/r/64003/diff/3/
> 
> 
> Testing
> -------
> 
> Fixed a few broken tests due to this patch.
> make check.
> 
> 
> Thanks,
> 
> Meng Zhu
> 
>


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