<div dir="ltr"><div>Hi,</div><div><br></div><div>I totally agree with Matt than `os-quota-class-sets` is inconsistent.</div><div>It has that hardcoded default class can't be changed. </div><div>API call is documented neither Nova nor Cinder (has the same API for quotas).</div><div><br></div><div>With defaults in the configuration I have some concerns:</div><div>- As it was mentioned before, possibly we need to update configs in several places.</div><div>- To make changes be applied we need to restart service, possibly SIGHUP can help</div><div>  but I'm not sure.</div><div><br></div><div>Alternatives I see are:</div><div>- Update `os-quota-sets` and give it possibility to work with defaults.</div><div>- Use external centralized quota service on which the work's doing actively.</div><div>  Please see [1] spec for limits in keystone and doc [2] having information</div><div>  how it can be applied in Nova and Cinder.</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/363765/">https://review.openstack.org/#/c/363765/</a></div><div>[2] <a href="https://docs.google.com/document/d/1AqmmRvd_e-4Hw2oLbnBf5jBtjLgMj-kqAaQfofp_NYI/edit#">https://docs.google.com/document/d/1AqmmRvd_e-4Hw2oLbnBf5jBtjLgMj-kqAaQfofp_NYI/edit#</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 15, 2016 at 6:32 AM, joehuang <span dir="ltr"><<a href="mailto:joehuang@huawei.com" target="_blank">joehuang@huawei.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we don't update the default quota configuration at the same time for Nova services in different<br>
physical nodes, then there is a chance for the quota control in dis-order period: for example,<br>
30 cores qutoa limit in one node, 20 cores quota limit in the other node.<br>
<br>
Best Regards<br>
Chaoyi Huang (joehuang)<br>
<br>
______________________________<wbr>__________<br>
From: Matt Riedemann [<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>]<br>
Sent: 15 December 2016 10:42<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: Re: [openstack-dev] [nova] Let's kill quota classes (again)<br>
<div class="HOEnZb"><div class="h5"><br>
On 7/18/2016 6:36 PM, Sean Dague wrote:<br>
> On 07/14/2016 08:07 AM, Kevin L. Mitchell wrote:<br>
>> The original concept of quota classes was to allow the default quotas<br>
>> applied to a tenant to be a function of the type of tenant.  That is,<br>
>> say you have a tiered setup, where you have gold-, silver-, and<br>
>> bronze-level customers, with gold having lots of free quota and bronze<br>
>> having a small amount of quota.  Rather than having to set the quotas<br>
>> individually for each tenant you created, the idea is that you set the<br>
>> _class_ of the tenant, and have quotas associated with the classes.<br>
>> This also has the advantage that, if someone levels up (or down) to<br>
>> another class of service, all you do is change the tenant's class, and<br>
>> the new quotas apply immediately.<br>
>><br>
>> (By the way, the turnstile integration was not part of turnstile itself;<br>
>> there's a turnstile plugin to allow it to integrate with nova that's<br>
>> quota_class-aware, so you could also apply rate limits this way.)<br>
>><br>
>> Personally, it wouldn't break my heart if quota classes went away; I<br>
>> think this level of functionality, if it seems reasonable to include,<br>
>> should become part of a more unified quota API (which we're still<br>
>> struggling to come up with anyway) so that everyone gets the benefit…or<br>
>> perhaps shares the pain? ;)  Anyway, I'm not aware of anyone using this<br>
>> functionality, though it might be worth asking about on the operators<br>
>> list—for curiosity's sake, if nothing else.  It would be interesting to<br>
>> see if anyone would be interested in the original idea, even if the<br>
>> current implementation doesn't make sense :)<br>
><br>
> We've already dropped the hook turnstile was using, so I don't see any<br>
> reason not to drop this bit as well. I don't think it will work for<br>
> anyone with the current code.<br>
><br>
> I agree that this probably makes way more sense in common quota code<br>
> then buried inside of Nova.<br>
><br>
>     -Sean<br>
><br>
<br>
Following up on this, I missed the boat for Ocata, but got to talking<br>
with melwitt about this again today and while I had it all in my head<br>
again I've written a spec for Pike to deprecate the os-quota-class-sets API:<br>
<br>
<a href="https://review.openstack.org/#/c/411035/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/411035/</a><br>
<br>
This essentially means no more custom quota classes (they aren't<br>
functional today anyway), and no more controlling global default quota<br>
limits via the REST API - that has to be done via the configuration<br>
(after the microversion).<br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div>Thanks,</div><div><br></div><div>Andrey Volkov,</div><div>Software Engineer, <span style="font-size:12.8px">Mirantis, Inc.</span></div></div></div></div></div></div>
</div>