Open Stack

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

-- 
Sean Dague
http://dague.net