<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 8 October 2014 04:13, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fainberg <span dir="ltr"><<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Keeping the enforcement local (same way policy works today) helps limit the fragility, big +1 there. <div><br></div><div>I also agree with Vish, we need a uniform way to talk about quota enforcement similar to how we have a uniform policy language / enforcement model (yes I know it's not perfect, but it's far closer to uniform than quota management is). <br></div></blockquote><div><br></div></span><div>It sounds like maybe we should have an oslo library for quotas? Somewhere where we can share the code,but keep the operations local to each service. </div></div></div></div></blockquote><div><br></div><div>This is what I had in mind as well. A simple library for quota enforcement which can be used regardless of where and how you do it, which might depend on the application business logic, the WSGI framework in use, or other factors.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div>If there is still interest of placing quota in keystone, let's talk about how that will work and what will be needed from Keystone . The previous attempt didn't get much traction and stalled out early in implementation. If we want to revisit this lets make sure we have the resources needed and spec(s) in progress / info on etherpads (similar to how the multitenancy stuff was handled at the last summit) as early as possible. </div></div></blockquote><div><br></div></span><div>Why not centralize quota management via the python-openstackclient, what is the benefit of getting keystone involved?</div></div></div></div></blockquote><div><br></div><div>Providing this through the openstack client in my opinion has the disadvantage that users which either use the REST API direct or write their own clients won't leverage it. I don't think it's a reasonable assumption that everybody will use python-openstackclient, is it?</div><div><br></div><div>Said that, storing quotas in keystone poses a further challenge to the scalability of the system, which we shall perhaps address by using appropriate caching strategies and leveraging keystone notifications. Until we get that, I think that the openstack client will be the best way of getting a unified quota management experience.</div><div><br></div><div>Salvatore</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div>Cheers,</div><div>Morgan</div><div><br></div><div>Sent via mobile<div><div><br><br>On Friday, October 3, 2014, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>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><div><br>
On Oct 3, 2014, at 7:53 AM, Duncan Thomas <<a>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>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>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>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>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>
</blockquote></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></div></div><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></div>