[openstack-dev] [cross-project] [all] Quotas -- service vs. library

Doug Hellmann doug at doughellmann.com
Wed Mar 16 13:53:22 UTC 2016

Excerpts from Sean Dague's message of 2016-03-16 06:09:47 -0400:
> On 03/16/2016 05:46 AM, Duncan Thomas wrote:
> > On 16 March 2016 at 09:15, Tim Bell <Tim.Bell at cern.ch
> > <mailto:Tim.Bell at cern.ch>> wrote:
> > 
> >     Then, there were major reservations from the PTLs at the impacts in
> >     terms of
> >     latency, ability to reconcile and loss of control (transactions are
> >     difficult, transactions
> >     across services more so).
> > 
> > 
> > Not just PTLs :-)
> >  
> > 
> >     <snip>
> >     I would favor a library, at least initially. If we cannot agree on a
> >     library, it
> >     is unlikely that we can get a service adopted (even if it is desirable).
> > 
> >     A library (along the lines of 1 or 2 above) would allow consistent
> >     implementation
> >     of nested quotas and user quotas. Nested quotas is currently only
> >     implemented
> >     in Cinder and user quota implementations vary between projects which is
> >     confusing.
> > 
> > 
> > It is worth noting that the cinder implementation has been found rather
> > lacking in correctness, atomicity requirements and testing - I wouldn't
> > suggest taking it as anything other than a PoC to be honest. Certainly
> > it should not be cargo-culted into another project in its present state.
> I think a library approach should probably start from scratch, with
> lessons learned from Cinder, but not really copied code, for just that
> reason.
> This is hard code to get right, which is why it's various degrees of
> wrong in every project in OpenStack.
> A common library with it's own db tables and migration train is the only
> way I can imagine this every getting accomplished given the atomicity
> and two phase commit constraints of getting quota on long lived, async
> created resources, with sub resources that also have quota. Definitely
> think that's the nearest term path to victory.

When we talked about this in Paris (I think, all these hotel basements
are starting to look the same), the main issue with the library was how
to tie in db table management with the existing tables owned by the app.
It's not impossible to solve, but we need some thought to happen
around the tools for that. Maybe some of the lessons of incremental
on-demand table updates in nova will help there.


More information about the OpenStack-dev mailing list