[openstack-dev] Quota management and enforcement across projects

Salvatore Orlando sorlando at nicira.com
Fri Oct 3 14:03:45 UTC 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141003/9ec6e688/attachment.html>


More information about the OpenStack-dev mailing list