mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Rukletsov" <ruklet...@gmail.com>
Subject Re: Review Request 35947: Added a new API call 'updateAvailable' to the allocator.
Date Wed, 08 Jul 2015 18:10:46 GMT


> On July 8, 2015, 5:37 p.m., Alexander Rukletsov wrote:
> > A high-level concern I would like to share with you guys, though it isn't directly
related to this particular patch. I have a feeling that we don't really care about keeping
the Allocator interface neat, brief, and concise, but rather abuse it and add random methods
to it in order to satisfy our current needs for the built-in allocator. With several production-grade
allocators on the market we won't be able to do this anymore. Shall we be more cautious about
that? Maybe it is a good time to schedule allocator refactoring?
> 
> Jie Yu wrote:
>     Alex, I totally agree with you that the current allocator interface needs a major
refactor. Given the recent Quota design, I feel like we should do the refactor asap, otherwise
the complexity will soon become unmanagable.
>     
>     I think the key is to define a clear boundary between master and allocator. Currently,
the boundary is not clear. For instance, the offer management is done by the master but we
have some interfaces like reviveOffers in the allocator.
>     
>     I would suggest that we open a ticket (or a doc) to list all the issues in the current
allocator interfaces, and then we can think about solutions. Does that sound good to you?

Jie, I'm so glad you share all my unsaid concerns (upcoming quota support, offers management,
responsibility separation between the master and the allocator)! I totally agree with your
proposal; one thing I would like to add is that it maybe makes sense to raise this concern
during the next community sync.


- Alexander


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


On June 26, 2015, 10:55 p.m., Michael Park wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/35947/
> -----------------------------------------------------------
> 
> (Updated June 26, 2015, 10:55 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Benjamin Hindman, Ben Mahler, and Jie
Yu.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Needed to implement the master HTTP endpoints: `/reserve`, `/unreserve`, `/create` and
`/destroy`.
> 
> This API is similar to `updateSlave` which is currently very specific to oversubscription.
> I considered consolidating `updateAvailable` and `updateSlave` but it will require making
offers be generated within the allocator to enable this.
> 
> In specific, `updateAvailable` could fail if there aren't sufficient available resources
to update, whereas `updateSlave` avoids failing by keeping the allocator in an over-allocated
state. For `updateSlave`, leaving the allocator in an over-allocated state is ok. This is
because it does not modify resources therefore `total - allocated` will work out to __empty__.
`updateAvailable` cannot leave the allocator in an over-allocated state, because it modifies
resources, and therefore `total - allocated` is not guaranteed to yield __empty__.
> 
> 
> Diffs
> -----
> 
>   include/mesos/master/allocator.hpp 22992c0c77058af4fcd28aa8e4a1191693a16f44 
>   src/master/allocator/mesos/allocator.hpp 72470ec7f56f84a9a9815c09adb88def90ef672f 
>   src/master/allocator/mesos/hierarchical.hpp 3264d145d52b48852878abf7ab9be29ab98208cc

>   src/tests/hierarchical_allocator_tests.cpp 3258840135290cd008ca09235d18b7f093dafd2e

>   src/tests/mesos.hpp 9157ac079808d2686592e54ea26a26e6a0825ed3 
> 
> Diff: https://reviews.apache.org/r/35947/diff/
> 
> 
> Testing
> -------
> 
> (1) Added `HierarchicalAllocatorTest.updateAvailableSuccess` and `HierarchicalAllocatorTest.updateAvailableFail`
> (2) `make check`
> 
> 
> Thanks,
> 
> Michael Park
> 
>


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