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
