mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Meng Zhu <m...@mesosphere.io>
Subject Re: Review Request 66982: Added a `decline` flag in `recoverResources` in the allocator.
Date Mon, 07 May 2018 22:44:41 GMT


> On May 7, 2018, 3:12 p.m., Vinod Kone wrote:
> > Do we need this optimization?

This is not an optimization. I think it is necessary for offer exhaustiveness to work properly.
The problem is that `recoverResources()` are used for all kinds of purposes and there is no
way for the allocator to know when an agent is actually declined by the framework. Do we want
a framework to be added to the exclusion set simply because its roles get updated or its offer
rescinded to meet other role's quota (and many other cases that has nothing to do with actual
framework decline).


- Meng


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


On May 6, 2018, 11:09 p.m., Meng Zhu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66982/
> -----------------------------------------------------------
> 
> (Updated May 6, 2018, 11:09 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler, Kapil Arya, Till Toenshoff, and Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> The `decline` flag acts as an hint to the allocator that this resource
> recover is triggered by the framework "declining" the offered resources.
> Currently this includes: framework `DECLINE` calls, framework `ACCEPT`
> calls with filters explicitly set and offer timeouts. Note, framework
> `ACCEPT` calls with unset filters (i.e. default filters) are not
> considered as "declining" offered resources.
> 
> 
> Diffs
> -----
> 
>   include/mesos/allocator/allocator.hpp e5a5355646c834280008867e89eb258eaefc2f1d 
>   src/master/allocator/mesos/allocator.hpp c453c015b234deff7efd00269da25dcec8cbf1ae 
>   src/master/allocator/mesos/hierarchical.hpp 955ae3e6a9e3c790fb260311ec4b4ef725a826d3

>   src/master/allocator/mesos/hierarchical.cpp 1000968be6a2935a4cac571414d7f06d7df7acf0

>   src/master/master.cpp 3b5d2eba3f602f68a6bb1e00444b01fb58a1bfc2 
>   src/tests/allocator.hpp 341efa665ad0ce897e087fb8d73ec50fd041d559 
>   src/tests/master_allocator_tests.cpp e1aef8a9625a805e7ad2dfad37bfeedee82f160d 
>   src/tests/slave_recovery_tests.cpp afe8b8a6cc21421a37164016d7fe01bf96a559da 
> 
> 
> Diff: https://reviews.apache.org/r/66982/diff/1/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Meng Zhu
> 
>


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