Hi Salvatore, 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. https://review.openstack.org/160605 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 ? best regards sajeesh ________________________________________ From: Tim Bell [tim.b...@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. > > 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 <s...@dague.net> wrote: > On 03/11/2015 08:31 PM, Joe Gordon wrote: > > > > > > On Wed, Mar 11, 2015 at 4:07 PM, Ihar Hrachyshka <ihrac...@redhat.com > > <mailto: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. > > > > > > 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-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