<div dir="ltr">Manila project does use "policy" common code from incubator.<div><br></div><div>Our "small" wrapper for it: <a href="https://github.com/openstack/manila/blob/8203c51081680a7a9dba30ae02d7c43d6e18a124/manila/policy.py" target="_blank">https://github.com/openstack/manila/blob/8203c51081680a7a9dba30ae02d7c43d6e18a124/manila/policy.py</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 15, 2014 at 2:41 AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.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">Doug,<div><br></div><div>I totally agree with your findings on the policy module.</div><div>Neutron already has some "customizations" there and we already have a few contributors working on syncing it back with oslo-incubator during the Kilo release cycle.</div><div><br></div><div>However, my query was about the quota module.</div><div>From what I gather it seems not a lot of projects use it:</div><div><br></div><div>$ find . -name openstack-common.conf | xargs grep quota<br>$</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Salvatore</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 15 October 2014 00:34, 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"><div style="word-wrap:break-word"><br><div><span><div>On Oct 14, 2014, at 12:31 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> wrote:</div><br><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></span><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><span><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></span><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" target="_blank">https://etherpad.openstack.org/p/kilo-oslo-library-proposals</a></div><div><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/" target="_blank">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><br>
On Oct 8, 2014, at 7:03 AM, Davanum Srinivas <<a href="mailto:davanum@gmail.com" target="_blank">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><font color="#888888"><br>
Doug<br>
</font></span><div><div><br>
><br>
> On Wed, Oct 8, 2014 at 2:29 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> wrote:<br>
>><br>
>> On 8 October 2014 04:13, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" 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>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> Duncan Thomas<br>
>>>>>>><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>
>>>>>><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>
>>>>><br>
>>>><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>
>>><br>
>>><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>
>><br>
>><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>
><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" 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>
<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>
</div></div></blockquote></div><br></div>
_______________________________________________<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></blockquote></div></div></div><br></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><br></div>
</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><br clear="all"><div><br></div>-- <br><div dir="ltr">Kind Regards<br>Valeriy Ponomaryov<br><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a><br><a href="mailto:vponomaryov@mirantis.com" target="_blank">vponomaryov@mirantis.com</a><br></div>
</div>