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

John Garbutt john at johngarbutt.com
Wed Mar 16 19:06:09 UTC 2016


On 16 March 2016 at 10:09, Sean Dague <sean at dague.net> wrote:
> 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.

+1

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

As an aside, I believe Neutron have had some recent success with a
quota re-write, although I have not dug into that.

In Nova we have been discussing a new approach to the DB storage of
the quota, loosely similar to the resource provider claims system we
are currently adding into the scheduler:
https://review.openstack.org/#/c/182445/4/specs/backlog/approved/quotas-reimagined.rst

We also discussed the idea of dropping a lot quota reservation
complexity. Rather than worrying if the async create server succeeds,
we could just commit the quota as soon as the server is recorded in
the db. This means an failed build consumes quota until the instance
is deleted, but that seems like a good trade off. Similarly, resize up
could just consume quota (until delete or revert resize), rather than
waiting for resize confirm.

Thanks,
johnthetubaguy



More information about the OpenStack-dev mailing list