Open Stack

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 <joehuang at 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 [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
>
> __________________________________________________________________________
> 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
>



-- 
Thanks,

Andrey Volkov,
Software Engineer, Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161215/89013376/attachment.html>