Open Stack

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 <robertc at robertcollins.net> wrote:

> On 12 March 2015 at 12:07, Ihar Hrachyshka <ihrachys at 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 <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150312/cb147664/attachment.html>