<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 27, 2014 at 1:11 PM, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Phil,<br>
<br>
You are correct and this seems to be an error. I don’t think in the earlier ML thread[1] that anyone remembered that the quota classes were being used for default quotas. IMO we need to revert this removal as we (accidentally) removed a Havana feature with no notification to the community. I’ve reactivated a bug[2] and marked it critcal.<br>

</blockquote><div><br></div><div>While I agree that we shouldn't have removed support for a working feature like updating the default quota via the REST API. I don't think we should just do a revert.</div><div><br>

</div><div>The good news is we haven't dropped any tables yet, so a revert won't require any migrations.</div><div><br></div><div>* quota-classes never worked for anything except changing default quotas, and this feature adds a whole bunch of DB calls to every quota lookup (a big overhead for a mostly broken feature). I am not a huge fan of bringing back a feature that is known to be mostly broken. I am also not a fan of breaking working features, which we did. Perhaps the right answer is to bring back just the default value override support.</div>

<div>* But having a rest API to override config file options sounds like a step in the wrong direction. I can see this easily leading to confusion about where the default quota values are coming from. This is part of a larger issue: folks want to update config options without restarting any services, as far as I know there is no reason why we cannot support this with minimal changes in a way that we can use this for other config options.</div>

<div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Vish<br>
<br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html</a><br>
[2] <a href="https://bugs.launchpad.net/nova/+bug/1299517" target="_blank">https://bugs.launchpad.net/nova/+bug/1299517</a><br>
<div class="HOEnZb"><div class="h5"><br>
On May 27, 2014, at 12:19 PM, Day, Phil <<a href="mailto:philip.day@hp.com">philip.day@hp.com</a>> wrote:<br>
<br>
> Hi Vish,<br>
><br>
> I think quota classes have been removed from Nova now.<br>
><br>
> Phil<br>
><br>
><br>
> Sent from Samsung Mobile<br>
><br>
><br>
> -------- Original message --------<br>
> From: Vishvananda Ishaya<br>
> Date:27/05/2014 19:24 (GMT+00:00)<br>
> To: "OpenStack Development Mailing List (not for usage questions)"<br>
> Subject: Re: [openstack-dev] [nova] nova default quotas<br>
><br>
> Are you aware that there is already a way to do this through the cli using quota-class-update?<br>
><br>
> <a href="http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html" target="_blank">http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html</a> (near the bottom)<br>
><br>
> Are you suggesting that we also add the ability to use just regular quota-update? I’m not sure i see the need for both.<br>
><br>
> Vish<br>
><br>
> On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J <<a href="mailto:sergio.j.cazzolato@intel.com">sergio.j.cazzolato@intel.com</a>> wrote:<br>
><br>
>> I would to hear your thoughts about an idea to add a way to manage the default quota values through the API.<br>
>><br>
>> The idea is to use the current quota api, but sending ''default' instead of the tenant_id. This change would apply to quota-show and quota-update methods.<br>
>><br>
>> This approach will help to simplify the implementation of another blueprint named per-flavor-quotas<br>
>><br>
>> Feedback? Suggestions?<br>
>><br>
>><br>
>> Sergio Juan Cazzolato<br>
>> Intel Software Argentina<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>