Open Stack

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 <klmitch at mit.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160714/a0c5e29e/attachment.pgp>