mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guangya Liu" <gyliu...@gmail.com>
Subject Re: Review Request 40632: Enabled oversubscribed resources for reservations in allocator.
Date Thu, 21 Jan 2016 07:06:08 GMT


> On 一月 16, 2016, 2:11 a.m., Joseph Wu wrote:
> > src/master/allocator/mesos/hierarchical.cpp, lines 1291-1319
> > <https://reviews.apache.org/r/40632/diff/15/?file=1195627#file1195627line1291>
> >
> >     None of this should be necessary:
> >     
> >     1) You should have all the allocation slack inside `available`.
> >     2) We don't have allocation slack ACLs in the MVP, so all allocation slack should
fall under `available.unreserved`.  If we do have ACLs, some of the allocation slack will
be accounted for in `available.reserved(role)`.
> >     3) You shouldn't need to recalculate this during `::allocate`.
> >     
> >     If any of the above are not true, you probably have a problem in the `Resource`
helpers or in `::addSlave`.
> 
> Guangya Liu wrote:
>     We can take a look at the following cases:
>     1) total resources cpus(r1):100
>     2) register a framework f1, cycle 1: allocated cpus(r1):100;cpu(*){ALLOCATION_SLACK}:100
to f1
>     3) f1 recovered cpu(*){ALLOCATION_SLACK}:100 back
>     4) register another framwork f2, f2 get nothing here as f1 used up all reserved resoures
and there is no allocation slack now.
>     
>     The above logic make sure that step 4) can always get the latest remaining allocation
slack.
> 
> Joseph Wu wrote:
>     The step 3) in your case is presumably because you haven't implemented all the allocator
methods yet (as of this review in the chain), like `recoverResources`, `updateAllocation`,
and `updateAvailable`.
>     
>     If so, you should consider moving the test additions/changes before/after (this lets
us know what your intended behavior is) the allocator changes.
> 
> Guangya Liu wrote:
>     I was updating the comments here to make it more clear.
>     
>     // Calculate the `remainingAllocationSlack` if the framework can
>     // use revocable resources and reservation oversubscription also
>     // enabled. The `remainingAllocationSlack` need to exclude the
>     // stateless reserved resources allocated in previous allocation
>     // cycle.
> 
> Joseph Wu wrote:
>     I would still **highly recommend** that you don't recalculate the allocation slack
inside a doubly-nested for-loop.
>     
>     And I'll reinterate: if you can't find the allocation slack inside the `available`
Resources object, then you're doing something wrong.  You should probably double-check if
this is the case.

The reason I need to recalcuate this is because for a role, let's say `r1`, the `r1`'s resources
including both `reserved` and `allocation slack` would be send out as an offer for `r1` if
a framework is using `r1`.

A case is as this:
1) agent1 with cpus(r1):100
2) add agent1, then agent1 reosurces will become cpus(r1):100;cpus(*){ALLOCATION_SLACK}:100
3) Register a framework with r1
4) The allocator will send out resources as cpus(r1):100;cpus(*){ALLOCATION_SLACK}:100. For
here, as we want thr framework can also run revocable tasks, so here, we are sending both
reserved and revocable resources to framework and let the framework select the resources.
5) The allcator recover the allocation slack
6) When allocate again, the allocator need to recalculate the allocation slack and found it
was 0

But if we do not send out both one role's `reserved` and `allocation slack`, we can simply
use the `allocation slack` in `available` resources.

This is a question that we need to discuss today: Do we need to send out the offer in one
role include both `reserved` and `allocation slack` ?


- Guangya


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


On 一月 20, 2016, 6:25 a.m., Guangya Liu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/40632/
> -----------------------------------------------------------
> 
> (Updated 一月 20, 2016, 6:25 a.m.)
> 
> 
> Review request for mesos, Ben Mahler, Artem Harutyunyan, Joris Van Remoortere, Joseph
Wu, Klaus Ma, and Jian Qiu.
> 
> 
> Bugs: MESOS-4145
>     https://issues.apache.org/jira/browse/MESOS-4145
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Enabled oversubscribed resources for reservations in allocator.
> The allocator part including 5 patches:
> 1) https://reviews.apache.org/r/40632 Enabled oversubscribed resources for reservations
in allocator
> 2) https://reviews.apache.org/r/41847 Updated allocation slack when slave was updated.
> 3) https://reviews.apache.org/r/41791 Updated allocation slack for dynamic reserve (1/3).
> 4) https://reviews.apache.org/r/42113 Handle unreserve logic for dynamic reservation
(2/3).
> 5) https://reviews.apache.org/r/42194 Handle unreserve logic for dynamic reservation
(3/3).
> 
> 
> Diffs
> -----
> 
>   src/master/allocator/mesos/hierarchical.cpp e32ee4aa3ed9793bb5a99233e699e5cc2bdd796b

>   src/tests/hierarchical_allocator_tests.cpp 953712149bd951789beb29c72779c4ac65aa48dc

> 
> Diff: https://reviews.apache.org/r/40632/diff/
> 
> 
> Testing
> -------
> 
> make
> make check
> GLOG_v=2  ./bin/mesos-tests.sh  --gtest_filter="HierarchicalAllocatorTest.*" --verbose
--gtest_repeat=100 --gtest_shuffle
> 
> 
> Thanks,
> 
> Guangya Liu
> 
>


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