<div dir="ltr"><div>It sounds like we're diverging a bit from the original topic, but... whatever.</div><div>Yeah! We should totally work towards a quota service - that's what we said back in 2011<br></div><div><br></div><div>This is a topic that comes back regularly like the Halley's comet. With the only difference that it happens every 6 months, not 75 years.</div><div>We explored options for a quota library or service in a few recent email threads and at the Paris summit.</div><div>It was concluded that since quota enforcement requires database support, and quota management needs to hook into some RESTful APIs, an oslo library was not the appropriate path forward.</div><div>Further options were explored, but the thing which is closest to what we'd need, from a conceptual point of view is Boson [1]. As you can see, the development there has been stalled for a while.</div><div>It was then considered how to move forward with boson, and how to integrate it in the current Openstack infrastructure. The most recent update on the mailing list is [2].</div><div>As you can see, there has not been any activity for a while there too.</div><div><br></div><div>I am still interested in resuming that work, and I am planning to come back to it after the Kilo-3 deadline. I am obviously still trying to look at building a group of developers interested in it.</div><div><br></div><div>Salvatore</div><div><br></div><div><br></div><div>[1] <a href="https://github.com/klmitch/boson">https://github.com/klmitch/boson</a></div><div>[2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-January/054510.html">http://lists.openstack.org/pipermail/openstack-dev/2015-January/054510.html</a></div><div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 11 March 2015 at 23:49, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 12 March 2015 at 12:07, Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>> wrote:<br>
> -----BEGIN PGP SIGNED MESSAGE-----<br>
> Hash: SHA1<br>
><br>
> On 03/11/2015 07:48 PM, Joe Gordon wrote:<br>
>> Out of sync Quotas ------------------<br>
>><br>
>> <a href="https://etherpad.openstack.org/p/PHL-ops-nova-feedback" target="_blank">https://etherpad.openstack.org/p/PHL-ops-nova-feedback</a> L63<br>
>><br>
>> The quotas code is quite racey (this is kind of a known if you look<br>
>> at the bug tracker). It was actually marked as a top soft spot<br>
>> during last fall's bug triage -<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html</a><br>
>><br>
>>  There is an operator proposed spec for an approach here -<br>
>> <a href="https://review.openstack.org/#/c/161782/" target="_blank">https://review.openstack.org/#/c/161782/</a><br>
>><br>
>> Action: we should make a solution here a top priority for enhanced<br>
>> testing and fixing in Liberty. Addressing this would remove a lot<br>
>> of pain from ops.<br>
>><br>
>><br>
>> To help us better track quota bugs I created a quotas tag:<br>
>><br>
>> <a href="https://bugs.launchpad.net/nova/+bugs?field.tag=quotas" target="_blank">https://bugs.launchpad.net/nova/+bugs?field.tag=quotas</a><br>
>><br>
>> Next step is re-triage those bugs: mark fixed bugs as fixed,<br>
>> deduplicate bugs etc.<br>
><br>
> (Being quite far from nova code, so ignore if not applicable)<br>
><br>
> I would like to note that other services experience races in quota<br>
> management too. Neutron has a spec approved to land in Kilo-3 that is<br>
> designed to introduce a new quota enforcement mechanism that is<br>
> expected to avoid (some of those) races:<br>
><br>
> <a href="https://github.com/openstack/neutron-specs/blob/master/specs/kilo/better-quotas.rst" target="_blank">https://github.com/openstack/neutron-specs/blob/master/specs/kilo/better-quotas.rst</a><br>
><br>
> I thought you may be interested in looking into it to apply similar<br>
> ideas to nova.<br>
<br>
</div></div>Seems to me that there is enough complexity around quotas that a<br>
dedicated quota REST service could be a good way to abstract that out<br>
- then in consuming code you can reserve, consume and free<br>
appropriately, and the service can take care of being super diligent<br>
about races, correctness, and we'd have one place both in code and<br>
deployments to tune for speed.<br>
<span class="im HOEnZb"><br>
-Rob<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
</span><div class="HOEnZb"><div class="h5">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</div></div></blockquote></div><br></div>