Open Stack

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 [mriedem at linux.vnet.ibm.com]
Sent: 15 December 2016 10:42
To: openstack-dev at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev