[openstack-dev] FW: [nova] readout from Philly Operators Meetup
Sajeesh Cimson Sasi
sajeesh.cs at cern.ch
Thu Mar 12 17:49:33 UTC 2015
We had a short discussion on Hierarchical quota management in nova somewhere in December. The spec was approved ,but the code couldn't make it to Kilo. I am trying to get it merged in Liberty. Implementation is over. Only test cases are pending.
I have resubmitted the specs for L release.
Kindly have a look at it.
You had told about quota management via oslo and storing quota values in keystone.Whether any progress has happened towards that direction ?
From: Tim Bell [Tim.Bell at cern.ch]
Sent: 12 March 2015 21:51:42
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] FW: [nova] readout from Philly Operators Meetup
> 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.
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.
> 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 Dague
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev