Open Stack

> I completely agree with you - Sean and Joe.
>
> Since the argument was brought up I just wanted to point out that this "quota service" thing is a bit of a unicorn at the moment, and it should not distract from fixing and improving quota maangement & enforcement logic in the various openstack projects.
>
> I wan't be able to introduce hierarchical quotas in neutron by the end of Kilo, but I'll keep it on the roadmap for Liberty.
>
> Salvatore
>

Given the hierarchical quotas make the quota handling more complex (to ensure parent quotas are consistent as well), this would seem a good candidate for an oslo library. During the Nova quota discussions, there was much consideration for how things would work and it would be a great cause of confusion if each project has its own approach/semantics.

A central quota service would then be a later decision which would have less impact if the code for quotas is shared.

Tim

> On 12 March 2015 at 11:59, Sean Dague <sean at dague.net> wrote:
> On 03/11/2015 08:31 PM, Joe Gordon wrote:
> >
> >
> > On Wed, Mar 11, 2015 at 4:07 PM, Ihar Hrachyshka <ihrachys at redhat.com
> > <mailto: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.
> >
> >
> > Working on a library for this hasn't been ruled out yet. But right now I
> > am simply trying to figure out how to reproduce the issue, and nothing else.
> Right, I think assuming an architecture change will magically fix this
> without scenarios that expose the existing bugs seems overly optimistic.
>
> I think there is a short / medium term test / reproduce question here,
> then a longer term question about different architecture.
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
> __________________________________________________________________________
> 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 embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150312/8f319f1e/attachment.txt>