Open Stack

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