Just a remark below w.r.t. quota support in some other projects fwiw.
On 09/03/18 15:46 +0800, Zhipeng Huang wrote:
Hi Team, Thanks to our topic leads' efforts, below is the aggregated summary from our dublin ptg session discussion. Please check it out and feel free to feedback any concerns you might have.
< -- snip -- >
Quota and Multi-tenancy Support Etherpad: https://etherpad.openstack.org/p/cyborg-ptg-rocky-quota Slide: https://docs.google.com/presentation/d/1DUKWW2vgqUI3Udl4UDvxgJ53Ve5LmyaBpX4u--rVrCc/edit?usp=sharing 1. Provide project and user level quota support 2. Treat all resources as the reserved resource type 3. Add quota engine and quota driver for the quota support 4. Tables: quotas, quota_usage, reservation 5. Transactions operation: reserve, commit, rollback - Concerns on rollback - Implement a two-stage resevation and rollback - reserve - commit - rollback (if failed)
Note that cinder and manila followed the nova implementation of a two-stage reservation/commit/rollback model but the resulting system has been buggy. Over time, the quota system's notion of resource usage gets out of sync with actual resource usage. Nova has since dropped the reserve/commit/rollback model [0] and cinder and manila are considering making a similar change. Currently we create reservation records and update quota usage in the API service and then remove the reservation records and update quota usage in another service at commit or rollback time, or on reservationtimeout. Nova now avoids the double bookkeeping of resource usage and the need to update these records correctly across separate services by directly checking resource counts in the api at the time requests are received. If we can do the same thing in cinder and manila a whole class of tough, recurrent bugs can be eliminated.
The main concern expressed thus far with this "resource counting" approach is that there may be some negative performance impact since the current approach provides cached usage information to the api service. As you can see here [1] there probably is not yet agreement on the degree of performance impact but there does seem to be agreement that we needfirst to get a quota system that is correct and reliable, then optimize for performance as needed.
Best regards, -- Tom Barron [0] https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/cells-count-resources-to-check-quota-in-api.html [1] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128108.html
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
