<div dir="ltr">Thanks Vish,<div><br></div><div>this seems a very reasonable first step as well - and since most projects would be enforcing quotas in the same way, the shared library would be the logical next step.</div><div>After all this is quite the same thing we do with authZ.</div><div><br></div><div>Duncan is expressing valid concerns which in my opinion can be addressed with an appropriate design - and a decent implementation.</div><div><br></div><div>Salvatore</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 October 2014 18:25, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The proposal in the past was to keep quota enforcement local, but to<br>
put the resource limits into keystone. This seems like an obvious first<br>
step to me. Then a shared library for enforcing quotas with decent<br>
performance should be next. The quota calls in nova are extremely<br>
inefficient right now and it will only get worse when we try to add<br>
hierarchical projects and quotas.<br>
<br>
Vish<br>
<div class="HOEnZb"><div class="h5"><br>
On Oct 3, 2014, at 7:53 AM, Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com">duncan.thomas@gmail.com</a>> wrote:<br>
<br>
> Taking quota out of the service / adding remote calls for quota<br>
> management is going to make things fragile - you've somehow got to<br>
> deal with the cases where your quota manager is slow, goes away,<br>
> hiccups, drops connections etc. You'll also need some way of<br>
> reconciling actual usage against quota usage periodically, to detect<br>
> problems.<br>
><br>
> On 3 October 2014 15:03, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
>> Hi,<br>
>><br>
>> Quota management is currently one of those things where every openstack<br>
>> project does its own thing. While quotas are obviously managed in a similar<br>
>> way for each project, there are subtle differences which ultimately result<br>
>> in lack of usability.<br>
>><br>
>> I recall that in the past there have been several calls for unifying quota<br>
>> management. The blueprint [1] for instance, hints at the possibility of<br>
>> storing quotas in keystone.<br>
>> On the other hand, the blazar project [2, 3] seems to aim at solving this<br>
>> problem for good enabling resource reservation and therefore potentially<br>
>> freeing openstack projects from managing and enforcing quotas.<br>
>><br>
>> While Blazar is definetely a good thing to have, I'm not entirely sure we<br>
>> want to make it a "required" component for every deployment. Perhaps single<br>
>> projects should still be able to enforce quota. On the other hand, at least<br>
>> on paper, the idea of making Keystone "THE" endpoint for managing quotas,<br>
>> and then letting the various project enforce them, sounds promising - is<br>
>> there any reason for which this blueprint is stalled to the point that it<br>
>> seems forgotten now?<br>
>><br>
>> I'm coming to the mailing list with these random questions about quota<br>
>> management, for two reasons:<br>
>> 1) despite developing and using openstack on a daily basis I'm still<br>
>> confused by quotas<br>
>> 2) I've found a race condition in neutron quotas and the fix is not trivial.<br>
>> So, rather than start coding right away, it might probably make more sense<br>
>> to ask the community if there is already a known better approach to quota<br>
>> management - and obviously enforcement.<br>
>><br>
>> Thanks in advance,<br>
>> Salvatore<br>
>><br>
>> [1] <a href="https://blueprints.launchpad.net/keystone/+spec/service-metadata" target="_blank">https://blueprints.launchpad.net/keystone/+spec/service-metadata</a><br>
>> [2] <a href="https://wiki.openstack.org/wiki/Blazar" target="_blank">https://wiki.openstack.org/wiki/Blazar</a><br>
>> [3] <a href="https://review.openstack.org/#/q/project:stackforge/blazar,n,z" target="_blank">https://review.openstack.org/#/q/project:stackforge/blazar,n,z</a><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Duncan Thomas<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>