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

Reply via email to