Open Stack

To complete the context:
https://review.openstack.org/#/c/132127/
https://etherpad.openstack.org/p/kilo-oslo-common-quota-library (from
https://wiki.openstack.org/wiki/Design_Summit/Kilo/Etherpads)

-- Dims

On Wed, Mar 16, 2016 at 9:53 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> 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.
>
> Doug
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims