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 <[email protected]> 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 <[email protected] >> > <mailto:[email protected]>> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
