It sounds like we're diverging a bit from the original topic, but... whatever. Yeah! We should totally work towards a quota service - that's what we said back in 2011
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. We explored options for a quota library or service in a few recent email threads and at the Paris summit. 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. 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. 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]. As you can see, there has not been any activity for a while there too. 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. Salvatore [1] https://github.com/klmitch/boson [2] http://lists.openstack.org/pipermail/openstack-dev/2015-January/054510.html On 11 March 2015 at 23:49, Robert Collins <robe...@robertcollins.net> wrote: > On 12 March 2015 at 12:07, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 03/11/2015 07:48 PM, Joe Gordon wrote: > >> Out of sync Quotas ------------------ > >> > >> https://etherpad.openstack.org/p/PHL-ops-nova-feedback L63 > >> > >> The quotas code is quite racey (this is kind of a known if you look > >> at the bug tracker). It was actually marked as a top soft spot > >> during last fall's bug triage - > >> > http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html > >> > >> There is an operator proposed spec for an approach here - > >> https://review.openstack.org/#/c/161782/ > >> > >> Action: we should make a solution here a top priority for enhanced > >> testing and fixing in Liberty. Addressing this would remove a lot > >> of pain from ops. > >> > >> > >> To help us better track quota bugs I created a quotas tag: > >> > >> https://bugs.launchpad.net/nova/+bugs?field.tag=quotas > >> > >> Next step is re-triage those bugs: mark fixed bugs as fixed, > >> deduplicate bugs etc. > > > > (Being quite far from nova code, so ignore if not applicable) > > > > I would like to note that other services experience races in quota > > management too. Neutron has a spec approved to land in Kilo-3 that is > > designed to introduce a new quota enforcement mechanism that is > > expected to avoid (some of those) races: > > > > > https://github.com/openstack/neutron-specs/blob/master/specs/kilo/better-quotas.rst > > > > I thought you may be interested in looking into it to apply similar > > ideas to nova. > > Seems to me that there is enough complexity around quotas that a > dedicated quota REST service could be a good way to abstract that out > - then in consuming code you can reserve, consume and free > appropriately, and the service can take care of being super diligent > about races, correctness, and we'd have one place both in code and > deployments to tune for speed. > > -Rob > > -- > Robert Collins <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > __________________________________________________________________________ > 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
