[openstack-dev] Quota management and enforcement across projects

Vishvananda Ishaya vishvananda at gmail.com
Fri Oct 3 16:25:46 UTC 2014


The proposal in the past was to keep quota enforcement local, but to
put the resource limits into keystone. This seems like an obvious first
step to me. Then a shared library for enforcing quotas with decent
performance should be next. The quota calls in nova are extremely
inefficient right now and it will only get worse when we try to add
hierarchical projects and quotas.

Vish

On Oct 3, 2014, at 7:53 AM, Duncan Thomas <duncan.thomas at gmail.com> wrote:

> Taking quota out of the service / adding remote calls for quota
> management is going to make things fragile - you've somehow got to
> deal with the cases where your quota manager is slow, goes away,
> hiccups, drops connections etc. You'll also need some way of
> reconciling actual usage against quota usage periodically, to detect
> problems.
> 
> On 3 October 2014 15:03, Salvatore Orlando <sorlando at nicira.com> wrote:
>> Hi,
>> 
>> Quota management is currently one of those things where every openstack
>> project does its own thing. While quotas are obviously managed in a similar
>> way for each project, there are subtle differences which ultimately result
>> in lack of usability.
>> 
>> I recall that in the past there have been several calls for unifying quota
>> management. The blueprint [1] for instance, hints at the possibility of
>> storing quotas in keystone.
>> On the other hand, the blazar project [2, 3] seems to aim at solving this
>> problem for good enabling resource reservation and therefore potentially
>> freeing openstack projects from managing and enforcing quotas.
>> 
>> While Blazar is definetely a good thing to have, I'm not entirely sure we
>> want to make it a "required" component for every deployment. Perhaps single
>> projects should still be able to enforce quota. On the other hand, at least
>> on paper, the idea of making Keystone "THE" endpoint for managing quotas,
>> and then letting the various project enforce them, sounds promising - is
>> there any reason for which this blueprint is stalled to the point that it
>> seems forgotten now?
>> 
>> I'm coming to the mailing list with these random questions about quota
>> management, for two reasons:
>> 1) despite developing and using openstack on a daily basis I'm still
>> confused by quotas
>> 2) I've found a race condition in neutron quotas and the fix is not trivial.
>> So, rather than start coding right away, it might probably make more sense
>> to ask the community if there is already a known better approach to quota
>> management - and obviously enforcement.
>> 
>> Thanks in advance,
>> Salvatore
>> 
>> [1] https://blueprints.launchpad.net/keystone/+spec/service-metadata
>> [2] https://wiki.openstack.org/wiki/Blazar
>> [3] https://review.openstack.org/#/q/project:stackforge/blazar,n,z
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> 
> 
> -- 
> Duncan Thomas
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141003/f5025f3d/attachment.pgp>


More information about the OpenStack-dev mailing list