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 :) On Wed, 2016-07-13 at 14:47 -0500, Matt Riedemann wrote: > We got a bug that the os-quota-class-sets API isn't documented: > > https://bugs.launchpad.net/nova/+bug/1602400 > > That's probably because we hate it and no one understands it. > > See this previous thread about trying to sort this out from the long > long ago: > > https://lists.launchpad.net/openstack/msg12200.html > > We tried killing it before, but it turns out, it's actually used by > something! > > http://lists.openstack.org/pipermail/openstack-dev/2014-May/036031.html > > But we didn't have integration testing in Tempest for default quotas at > that time (we added those tests in when we reverted the delete of the > API back in Juno). > > I got looking at this because of the quota_class attribute in the nova > RequestContext: > > https://github.com/openstack/nova/blob/93cc5e3ffd2867bdb39a707a230c1efc6ed2f5f4/nova/context.py#L138-L141 > > That led me to markmc's thread about that only being there for the > turnstile project and some old API rate limiting stuff that Rackspace > was doing out of tree (it appears to set a type of middleware for a > quota class for rate limiting). > > Anyway, super duper out of tree stuff that is probably not even used > anymore (Vek - if you're reading, please speak up). > > I'll also point out that API rate limiting as a paste config was only in > the v2 API and that code was all dropped and the API rate limiting stuff > wasn't carried over for the v2.1 API, for good reason, see: > > http://lists.openstack.org/pipermail/openstack-operators/2016-June/010692.html > > You can still create unique quota classes via the os-quota-class-sets > API (it does a create if the update operation fails), but as far as I > can tell you can't really use those in any meaningful way. > > We really just have the 'default' quota class with a buttload of code > and plumbing to use that, which sucks, because it's all very complicated. > > So I think I'm going to start a pet project of rooting this stuff out > again, starting with nova.context.RequestContext.quota_class, unless > anyone has a good reason we should keep this in tree. > > I think we should also add a microversion to the API in Ocata to disable > the ability to create new quota classes, so that update is only update, > and a 404 for anything else. > -- Kevin L. Mitchell <[email protected]>
signature.asc
Description: This is a digitally signed message part
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
