What about "Global Reservations"? On Thu, Jul 9, 2015 at 3:25 PM, Marco Massenzio <[email protected]> wrote:
> I've added my twocent in the doc - my vote goes for "Guaranteed Allocation" > - not as catchy as "Quota" (and will make classes' naming a challenge!) but > maybe more helpful in the long-term. > > Anyone has a better suggestion, please do... I can't really say I'm > super-excited by Guaranteed Allocation myself! > > *Marco Massenzio* > *Distributed Systems Engineer* > > On Thu, Jul 9, 2015 at 1:48 AM, Alex Rukletsov <[email protected]> > wrote: > > > And you're not the only one who were confused by the terminology! One of > > the alternatives that didn't make it to the public doc was "cluster-wide > > dynamic reservations". The reason we preferred "quota" to " ... > > reservation" is because the latter is already overloaded with meanings in > > Mesos world (static reservations, dynamic reservations). I have hoped the > > Terminology section would have helped to avoid the confusion, but I see > it > > doesn't. We'll think about how we can solve the problem, we definitely > > don't want to create one more "libprocess process represented as a thread > > in an OS process" ; ). > > > > I see your point regarding authorization, you're not alone here either : > ). > > Some folks mentioned that the lack of authz is a blocker and will prevent > > them from upgrading the cluster. I would propose to treat MVP as > > experimental feature: use it at your own risk or disable endpoints > related > > to quota and hence the entire feature. Does it make sense? > > > > On Wed, Jul 8, 2015 at 7:10 PM, James Peach <[email protected]> wrote: > > > > > > > > > On 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 most confusing part of this document to me was the 'quota' > > > terminology. Quotas normally refer to administrative limits (esp. disk > > > quotas with hard and soft limits), not reserving resources. Since what > > you > > > are describing is an extension to the resource reservation system, it > > would > > > be clearer if it was described in those terms. > > > > > > I was also concerned that access control / authorization is not planned > > > for the initial implementation. I think that if Mesos is to have an > > > authorization policy, it should be applied uniformly following the > > > principle of least surprise. > > > > > > > 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 > > > > > > > > >
