If we don't update the default quota configuration at the same time for Nova services in different physical nodes, then there is a chance for the quota control in dis-order period: for example, 30 cores qutoa limit in one node, 20 cores quota limit in the other node.
Best Regards Chaoyi Huang (joehuang) ________________________________________ From: Matt Riedemann [mrie...@linux.vnet.ibm.com] Sent: 15 December 2016 10:42 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Let's kill quota classes (again) On 7/18/2016 6:36 PM, Sean Dague wrote: > On 07/14/2016 08:07 AM, Kevin L. Mitchell wrote: >> The original concept of quota classes was to allow the default quotas >> applied to a tenant to be a function of the type of tenant. That is, >> say you have a tiered setup, where you have gold-, silver-, and >> bronze-level customers, with gold having lots of free quota and bronze >> having a small amount of quota. Rather than having to set the quotas >> individually for each tenant you created, the idea is that you set the >> _class_ of the tenant, and have quotas associated with the classes. >> This also has the advantage that, if someone levels up (or down) to >> another class of service, all you do is change the tenant's class, and >> the new quotas apply immediately. >> >> (By the way, the turnstile integration was not part of turnstile itself; >> there's a turnstile plugin to allow it to integrate with nova that's >> quota_class-aware, so you could also apply rate limits this way.) >> >> Personally, it wouldn't break my heart if quota classes went away; I >> think this level of functionality, if it seems reasonable to include, >> should become part of a more unified quota API (which we're still >> struggling to come up with anyway) so that everyone gets the benefit…or >> perhaps shares the pain? ;) Anyway, I'm not aware of anyone using this >> functionality, though it might be worth asking about on the operators >> list—for curiosity's sake, if nothing else. It would be interesting to >> see if anyone would be interested in the original idea, even if the >> current implementation doesn't make sense :) > > We've already dropped the hook turnstile was using, so I don't see any > reason not to drop this bit as well. I don't think it will work for > anyone with the current code. > > I agree that this probably makes way more sense in common quota code > then buried inside of Nova. > > -Sean > Following up on this, I missed the boat for Ocata, but got to talking with melwitt about this again today and while I had it all in my head again I've written a spec for Pike to deprecate the os-quota-class-sets API: https://review.openstack.org/#/c/411035/ This essentially means no more custom quota classes (they aren't functional today anyway), and no more controlling global default quota limits via the REST API - that has to be done via the configuration (after the microversion). -- Thanks, Matt Riedemann __________________________________________________________________________ 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 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