Great work guys! Couple of related high level questions, mostly around customization:
(1) I imagine some folks may not want to use an endpoint for this. For example, they may want the master to consult an external quota database, file, etc as it is a bit easier to guarantee convergence with this approach. Also might be easier when there are a large number of users (e.g. O(1000s)). How does this fit into the current design? (2) The design has the master acting as a quota database, which seems to imply that quota policy lies outside mesos (e.g. it's not up to mesos to determine whether ben is _allowed_ to have 100GB of memory in the cluster, or if that is _too much_), since these policies can be arbitrarily complicated. If this is the case, the externally stored quota (e.g. in a quota database, file, etc) will get fed into mesos continually, so it seems a bit odd for mesos to be rejecting these requests, rather than accepting them and trying our best to eventually satisfy them? Perhaps we're missing a user story related to this? On Sat, Jul 4, 2015 at 3:15 AM, Alex Rukletsov <[email protected]> wrote: > Folks, > > Jörg and I are working on adding *quota* support to Mesos. Quota can be > described as cluster-wide dynamic reservation. I would like to share the > design doc [1] to gather community feedback early in the design phase. > > The doc is work in progress, especially the part related to quota support > in the allocator. We think we can start working on adding quota support to > Mesos Master while fleshing out the design for how quota is handled by the > built-in allocator. > > While working on the design, we faced some challenges and design questions. > One of them is what decisions should be deferred to allocator and what can > be decided by the Master. We elaborate on this in the doc. > > Looking forward to your feedback! > > [1]: > > https://docs.google.com/document/d/16iRNmziasEjVOblYp5bbkeBZ7pnjNlaIzPQqMTHQ-9I/edit?usp=sharing >
