Re: [openstack-dev] [cross-project] [all] Quotas and the need for reservation
>It is believed that reservation help to to reserve a set of resources >beforehand and hence eventually preventing any other upcoming request >(serial or parallel) to exceed quota if because of original request the >project might have reached the quota limits. > >Questions :- >1. Does reservation in its current state as used by Nova, Cinder, Neutron >help to solve the above problem ? In Cinder the reservations are useful for grouping quota for a single request, and if the request ends up failing the reservation gets rolled back. The reservations also rollback automatically if not committed within a certain time. We also use reservations with Cinder nested quotas to group a usage request that may propagate up to a parent project in order to manage commit/rollback of the request as a single unit. > >2. Is it consistent, reliable ? Even with reservation can we run into >in-consistent behaviour ? Others can probably answer this better, but I have not seen the reservations be a major issue. In general with quotas we're not doing the check and set atomically which can get us in an inconsistent state with quota-update, but that's unrelated to the reservations. > >3. Do we really need it ? > Seems like we need *some* way of keeping track of usage reserved during a particular request and a way to easily roll that back at a later time. I'm open to alternatives to reservations, just wondering what the big downside of the current reservation system is. - Ryan McNair (mc_nair) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] Nested quota -1 limit race condition
Hey all, Nested quotas has officially started fighting back - while writing Tempest tests for the nested quota support [1], I hit a race-condition related to the nested quota -1 support that has me stumped. I opened a bug for it [2] with more details, but basically the issue occurs when if you change a limit to or from -1 for a project while at the same time creating volumes on the project (or on it's subtree if child is using -1 also). Trying to figure out how to best handle this. Whether suggestions for how to fix this, thoughts on how critical this situation is, whether we should disable -1 support for now, etc. - all input is welcome. Thanks, Ryan McNair (mc_nair) [1] https://review.openstack.org/#/c/285640/2 [2] https://bugs.launchpad.net/cinder/+bug/1552944 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][cinder] Projects acting as a domain at the top of the project hierarchy
So just recapping, http://review.openstack.org/#/c/274825 separates Cinder NestedQuota support into its own driver which is no longer the default. Once ^ lands, http://review.openstack.org/#/c/231289 should no longer be blocked in Tempest (because NestedQuotas support won't get flexed by default). After the Keystone change lands, I will update the NestedQuota support to handle domain_id being the parent of a top level project, and then update Tempest tests so we get coverage on both Cinder nested and non-nested quotas. - Ryan McNair (mc_nair) > Henry, > I know about two patches related: > Fixes cinder quota mgmt for keystone v3 - > https://review.openstack.org/#/c/253759 > Split out NestedQuotas into a separate driver - > https://review.openstack.org/#/c/274825 > > The first one was abandoned, so I think the second patch is enough to fix > this issue. > > Cheers, > Raildo __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
