
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Oct 14, 2014, at 12:31 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi Doug,<div><br></div><div>do you know if the existing quota oslo-incubator module has already some active consumers?</div><div>In the meanwhile I've pushed a spec to neutron-specs for improving quota management there [1]</div></div></blockquote><div><br></div><div>It looks like a lot of projects are syncing the module:</div><div><br></div><div><div>$ grep policy */openstack-common.conf</div><div>barbican/openstack-common.conf:modules=gettextutils,jsonutils,log,local,timeutils,importutils,policy</div><div>ceilometer/openstack-common.conf:module=policy</div><div>cinder/openstack-common.conf:module=policy</div><div>designate/openstack-common.conf:module=policy</div><div>gantt/openstack-common.conf:module=policy</div><div>glance/openstack-common.conf:module=policy</div><div>heat/openstack-common.conf:module=policy</div><div>horizon/openstack-common.conf:module=policy</div><div>ironic/openstack-common.conf:module=policy</div><div>keystone/openstack-common.conf:module=policy</div><div>manila/openstack-common.conf:module=policy</div><div>neutron/openstack-common.conf:module=policy</div><div>nova/openstack-common.conf:module=policy</div><div>trove/openstack-common.conf:module=policy</div><div>tuskar/openstack-common.conf:module=policy</div><div><br></div><div>I’m not sure how many are actively using it, but I wouldn’t expect them to copy it in if they weren’t using it at all.</div></div><br><blockquote type="cite"><div dir="ltr"><div><br></div><div>Now, I can either work on the oslo-incubator module and leverage it in Neutron, or develop the quota module in Neutron, and move it to oslo-incubator once we validate it with Neutron. The latter approach seems easier from a workflow perspective - as it avoid the intermediate steps of moving code from oslo-incubator to neutron. On the other hand it will delay adoption in oslo-incubator.</div></div></blockquote><div><br></div><div>The policy module is up for graduation this cycle. It may end up in its own library, to allow us to build a review team for the code more easily than if we put it in with some of the other semi-related modules like the server code. We’re still working that out [1], and if you expect to make a lot of incompatible changes we should delay graduation to make that simpler.</div><div><br></div><div>Either way, since we have so many consumers, I think it would be easier to have the work happen in Oslo somewhere so we can ensure those changes are useful to and usable by all of the existing consumers.</div><div><br></div><div>Doug</div><div><br></div><div>[1] <a href="https://etherpad.openstack.org/p/kilo-oslo-library-proposals">https://etherpad.openstack.org/p/kilo-oslo-library-proposals</a></div><br><blockquote type="cite"><div dir="ltr"><div><br></div><div>What's your opinion?</div><div><br></div><div>Regards,</div><div>Salvatore</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/128318/">https://review.openstack.org/#/c/128318/</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 October 2014 18:52, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>

On Oct 8, 2014, at 7:03 AM, Davanum Srinivas <<a href="mailto:davanum@gmail.com">davanum@gmail.com</a>> wrote:<br>

<br>

> Salvatore, Joe,<br>

><br>

> We do have this at the moment:<br>

><br>

> <a href="https://github.com/openstack/oslo-incubator/blob/master/openstack/common/quota.py" target="_blank">https://github.com/openstack/oslo-incubator/blob/master/openstack/common/quota.py</a><br>

><br>

</span>> — dims<br>

<br>

If someone wants to drive creating a useful library during kilo, please consider adding the topic to the etherpad we’re using to plan summit sessions and then come participate in the Oslo meeting this Friday 16:00 UTC.<br>

<br>

<a href="https://etherpad.openstack.org/p/kilo-oslo-summit-topics" target="_blank">https://etherpad.openstack.org/p/kilo-oslo-summit-topics</a><br>

<span class="HOEnZb"><font color="#888888"><br>

Doug<br>

</font></span><div class="HOEnZb"><div class="h5"><br>

><br>

> On Wed, Oct 8, 2014 at 2:29 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>

>><br>

>> On 8 October 2014 04:13, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>> wrote:<br>

>>><br>

>>><br>

>>> On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fainberg<br>

>>> <<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@gmail.com</a>> wrote:<br>

>>>><br>

>>>> Keeping the enforcement local (same way policy works today) helps limit<br>

>>>> the fragility, big +1 there.<br>

>>>><br>

>>>> I also agree with Vish, we need a uniform way to talk about quota<br>

>>>> enforcement similar to how we have a uniform policy language / enforcement<br>

>>>> model (yes I know it's not perfect, but it's far closer to uniform than<br>

>>>> quota management is).<br>

>>><br>

>>><br>

>>> It sounds like maybe we should have an oslo library for quotas? Somewhere<br>

>>> where we can share the code,but keep the operations local to each service.<br>

>><br>

>><br>

>> This is what I had in mind as well. A simple library for quota enforcement<br>

>> which can be used regardless of where and how you do it, which might depend<br>

>> on the application business logic, the WSGI framework in use, or other<br>

>> factors.<br>

>><br>

>>><br>

>>>><br>

>>>><br>

>>>> If there is still interest of placing quota in keystone, let's talk about<br>

>>>> how that will work and what will be needed from Keystone . The previous<br>

>>>> attempt didn't get much traction and stalled out early in implementation. If<br>

>>>> we want to revisit this lets make sure we have the resources needed and<br>

>>>> spec(s) in progress / info on etherpads (similar to how the multitenancy<br>

>>>> stuff was handled at the last summit) as early as possible.<br>

>>><br>

>>><br>

>>> Why not centralize quota management via the python-openstackclient, what<br>

>>> is the benefit of getting keystone involved?<br>

>><br>

>><br>

>> Providing this through the openstack client in my opinion has the<br>

>> disadvantage that users which either use the REST API direct or write their<br>

>> own clients won't leverage it. I don't think it's a reasonable assumption<br>

>> that everybody will use python-openstackclient, is it?<br>

>><br>

>> Said that, storing quotas in keystone poses a further challenge to the<br>

>> scalability of the system, which we shall perhaps address by using<br>

>> appropriate caching strategies and leveraging keystone notifications. Until<br>

>> we get that, I think that the openstack client will be the best way of<br>

>> getting a unified quota management experience.<br>

>><br>

>> Salvatore<br>

>><br>

>><br>

>>>><br>

>>>> Cheers,<br>

>>>> Morgan<br>

>>>><br>

>>>> Sent via mobile<br>

>>>><br>

>>>><br>

>>>> On Friday, October 3, 2014, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>><br>

>>>> wrote:<br>

>>>>><br>

>>>>> Thanks Vish,<br>

>>>>><br>

>>>>> this seems a very reasonable first step as well - and since most<br>

>>>>> projects would be enforcing quotas in the same way, the shared library would<br>

>>>>> be the logical next step.<br>

>>>>> After all this is quite the same thing we do with authZ.<br>

>>>>><br>

>>>>> Duncan is expressing valid concerns which in my opinion can be addressed<br>

>>>>> with an appropriate design - and a decent implementation.<br>

>>>>><br>

>>>>> Salvatore<br>

>>>>><br>

>>>>> On 3 October 2014 18:25, Vishvananda Ishaya <<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>><br>

>>>>> wrote:<br>

>>>>>><br>

>>>>>> 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>

>>>>>><br>

>>>>>> On Oct 3, 2014, at 7:53 AM, Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com">duncan.thomas@gmail.com</a>><br>

>>>>>> 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>><br>

>>>>>>> wrote:<br>

>>>>>>>> Hi,<br>

>>>>>>>><br>

>>>>>>>> Quota management is currently one of those things where every<br>

>>>>>>>> openstack<br>

>>>>>>>> project does its own thing. While quotas are obviously managed in a<br>

>>>>>>>> similar<br>

>>>>>>>> way for each project, there are subtle differences which ultimately<br>

>>>>>>>> result<br>

>>>>>>>> in lack of usability.<br>

>>>>>>>><br>

>>>>>>>> I recall that in the past there have been several calls for unifying<br>

>>>>>>>> quota<br>

>>>>>>>> management. The blueprint [1] for instance, hints at the possibility<br>

>>>>>>>> of<br>

>>>>>>>> storing quotas in keystone.<br>

>>>>>>>> On the other hand, the blazar project [2, 3] seems to aim at solving<br>

>>>>>>>> this<br>

>>>>>>>> problem for good enabling resource reservation and therefore<br>

>>>>>>>> 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<br>

>>>>>>>> sure we<br>

>>>>>>>> want to make it a "required" component for every deployment. Perhaps<br>

>>>>>>>> single<br>

>>>>>>>> projects should still be able to enforce quota. On the other hand,<br>

>>>>>>>> at least<br>

>>>>>>>> on paper, the idea of making Keystone "THE" endpoint for managing<br>

>>>>>>>> quotas,<br>

>>>>>>>> and then letting the various project enforce them, sounds promising<br>

>>>>>>>> - is<br>

>>>>>>>> there any reason for which this blueprint is stalled to the point<br>

>>>>>>>> that it<br>

>>>>>>>> seems forgotten now?<br>

>>>>>>>><br>

>>>>>>>> I'm coming to the mailing list with these random questions about<br>

>>>>>>>> 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<br>

>>>>>>>> trivial.<br>

>>>>>>>> So, rather than start coding right away, it might probably make more<br>

>>>>>>>> sense<br>

>>>>>>>> to ask the community if there is already a known better approach to<br>

>>>>>>>> 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>

>>>>>><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>

>>>> 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>

>>> 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>

>> 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>

> Davanum Srinivas :: <a href="https://twitter.com/dims" target="_blank">https://twitter.com/dims</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>

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>

</div></div></blockquote></div><br></div>

_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></body></html>