Hi, I totally agree with Matt than `os-quota-class-sets` is inconsistent. It has that hardcoded default class can't be changed. API call is documented neither Nova nor Cinder (has the same API for quotas).
With defaults in the configuration I have some concerns: - As it was mentioned before, possibly we need to update configs in several places. - To make changes be applied we need to restart service, possibly SIGHUP can help but I'm not sure. Alternatives I see are: - Update `os-quota-sets` and give it possibility to work with defaults. - Use external centralized quota service on which the work's doing actively. Please see [1] spec for limits in keystone and doc [2] having information how it can be applied in Nova and Cinder. [1] https://review.openstack.org/#/c/363765/ [2] https://docs.google.com/document/d/1AqmmRvd_e-4Hw2oLbnBf5jBtjLgMj-kqAaQfofp_NYI/edit# On Thu, Dec 15, 2016 at 6:32 AM, joehuang <joehu...@huawei.com> wrote: > 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 > -- Thanks, Andrey Volkov, Software Engineer, Mirantis, Inc.
__________________________________________________________________________ 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