<div dir="ltr">Hi all,<div><br></div><div>I am resuming this thread following the session we had at the summit in Paris (etherpad here [1])</div><div><br></div><div>While there was some sort of consensus regarding what this library should do, and how it should do it, the session ended with some open questions which we need to address before finalising the specification.<br></div><div><br></div><div>There was a rather large consensus that the only viable architecture would be one where the quota management library owns resource usage data. However, this raises further concerns around:</div><div>- ownership of resource usage records. As the quota library owns usage data, it becomes the authoritative source of truth for it. This could be problematic in some projects, particularly nova, where the resource tracker currently own usage data.</div><div>- inserting quota-related db migrations in the consumer project timeline. We'll need to solve this for both sqlalchemy.migrate and alembic (I seem to recall Doug has a solution for this)</div><div><br></div><div>While the proposed interface for quota enforcing was generally well received, another open question is whether this library should also be responsible for quota management. Each project currently exposes its own extension for setting quotas for tenants, and this is rather bad from an usability perspective. whether this should be responsibility of the quota library, handle by a separate "quota service", or handled through keystone is debatable. Personally I think the library should not get in the business of defining APIs. However, it can define the business logic for managing tenant quotas which can then be leveraged by the projects which will adopt it. Either way, I reckon that we might be better off by limiting our scope to quota enforcement for the first iteration of this library.</div><div><br></div><div>The last, and possibly most important question, is whether this library belongs to the oslo-incubator or should live into its own repository. I would personally prefer the oslo incubator because its process makes adoption by OpenStack projects fairly simple. On the other hand, I also understand the concerns around a library that comes with its own data models and has the potential of becoming something bigger than a simple library. I would like to defer an answer to this question to the oslo core team, which are surely a lot more experienced than me on the matter of the incubator.</div><div><br></div><div>To this aim, the proposed specification [2] has been temporarily put in WIP.</div><div><br></div><div>A few more notes:</div><div><br></div><div>1) We agreed that we won't be constrained about saving any part of the current module, since it's not used by any project. We will however reuse whatever can be reused (mostly for not wasting time by writing the same thing again)</div><div><br></div><div>2) As concerns data backends to support, we agreed that we would start with the simplest possible solution. A single SQLalchemy-backed data source. Potentially we won't even have a framework for plugging different kind of data sources. However if contributors step in with support for multiple backends, we will consider it. </div><div><br></div><div>3) The idea of having a quota engine leveraging "data sources" was quite welcomed. Ideally it's not that different from the engine/driver model in the current module, but there will be a cleaner separation of responsibilities.</div><div><br></div><div>Salvatore</div><div><br></div><div>[1] <a href="https://etherpad.openstack.org/p/kilo-oslo-common-quota-library">https://etherpad.openstack.org/p/kilo-oslo-common-quota-library</a></div><div>[2] <a href="https://review.openstack.org/#/c/132127/">https://review.openstack.org/#/c/132127/</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 October 2014 20:54, 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">We can make it support whatever we want! :-)<div><br></div><div>The existing code almost certainly predates domain support in keystone, so I think this is a case of needing to catch up not a conscious decision to leave it out.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">Doug</font></span><div><div class="h5"><br><div><br><div><div>On Oct 15, 2014, at 12:15 PM, Ajaya Agrawal <<a href="mailto:ajku.agr@gmail.com" target="_blank">ajku.agr@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Hi,<div><br></div><div>Would the new library support quota on domain level also? As it stands in oslo-incubator it only does quota enforcement on project level only. The use case for this is quota enforcement across multiple projects. For e.g. as a cloud provider, I would like my customer to create only #X volumes across all his projects.</div><div><br></div><div>-Ajaya</div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div>Cheers,<br></div>Ajaya<br></div></div>
<br><div class="gmail_quote">On Wed, Oct 15, 2014 at 7:04 PM, 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">Sigh. Because I typed the wrong command. Thanks for pointing that out.<div><br></div><div>I don’t see any instances of “quota” in openstack-common.conf files:</div><div><br></div><div>$ grep quota */openstack-common.conf</div><div><br></div><div>or in any projects under "openstack/“:</div><div><br></div><div>$ ls */*/openstack/common/quota.py</div><div>ls: cannot access */*/openstack/common/quota.py: No such file or directory</div><div><br></div><div>I don’t know where manila’s copy came from, but if it has been copied from the incubator by hand and then changed we should fix that up.</div><span><font color="#888888"><div><br></div><div>Doug</div></font></span><div><div><br><div><div>On Oct 15, 2014, at 5:28 AM, Valeriy Ponomaryov <<a href="mailto:vponomaryov@mirantis.com" target="_blank">vponomaryov@mirantis.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">But why "policy" is being discussed on "quota" thread?</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 15, 2014 at 11:55 AM, Valeriy Ponomaryov <span dir="ltr"><<a href="mailto:vponomaryov@mirantis.com" target="_blank">vponomaryov@mirantis.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">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"><div><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><font color="#888888"><div><br></div><div>Salvatore</div></font></span></div><div><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><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><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></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><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><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><br clear="all"><div><br></div>-- <br></div><div dir="ltr">Kind Regards<span><font color="#888888"><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></font></span></div>
</div>
</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>
_______________________________________________<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><br></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><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><br></div></div></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></div>