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