<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Kevin,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I don't suggest to use random IDs as artifact identifiers in the community app catalog. Of course we will need to have some globally unique names there (my initial idea on that is to have a combination of fully-qualified namespace-based name + version + signature) - and such names should be used to replicate artifacts across the cloud boundaries.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">By "Referencing by ID" I mean only the local referencing: when the artifact is already present in cloud's local Glance (be it imported from the community catalog, copied from other cloud or uploaded directly), the particular service (Heat in our example) should be able to consume it by ID, same as Nova currently does with Images.</div><div class="gmail_default" style="font-size:small">This has its own purpose to guarantee objects' immutability: once the user has selected an object in the local catalog, she may be sure that nobody will interfere and modify it, as the object itself is immutable and the id is not reusable. If the object is referenced only by name, then it may be deleted and a different artifact with the same name may be uploaded instead, which may introduce a potential security issue. Using IDs will prevent such behavior.</div><div class="gmail_default" style="font-size:small">Fully qualified object names are still needed, of course - but that's Glance goal to locate an artifact based on its FQN and return the id for it. </div><div class="gmail_default" style="font-size:small">At least, this was the design idea of the initial artifact concept.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But that's an off-topic here, as this concept is related only to the local artifact repos, and world-global app catalog has nothing to do with this. </div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><font size="2">--<br></font><div dir="ltr"><font size="2">Regards,<br>Alexander Tivelkov</font></div></div></div></div>
<br><div class="gmail_quote">On Fri, May 29, 2015 at 6:47 PM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">Hi Alexander,<br>
<br>
Sweet. I'll have to kick the tires on the current state of Liberty soon. :)<br>
<br>
Reference by artifact IDs is going to be problematic I think. How do you release a generic set of resources to the world that reference specific randomly generated ID's?<br>
<br>
What about by Name? If not, then it will need to be some kind of mapping mechanism. :/<br>
<br>
Thanks,<br>
Kevin<br>
<br>
<div style="font-family:Times New Roman;color:#000000;font-size:16px">
<hr>
<div style="direction:ltr"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Alexander Tivelkov [<a href="mailto:ativelkov@mirantis.com" target="_blank">ativelkov@mirantis.com</a>]<br>
<b>Sent:</b> Friday, May 29, 2015 4:19 AM<div><div class="h5"><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [new][app-catalog] App Catalog next steps<br>
</div></div></font><br>
</div><div><div class="h5">
<div></div>
<div>
<div dir="ltr">
<div class="gmail_default" style="font-size:small">Hi Kevin,</div>
<div class="gmail_extra">
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">Has the Glance Artifact Repository implemented enough bits to have Heat and/or Murano artefacts yet?
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div class="gmail_default" style="font-size:small">Most of the code is there already, couple of patchsets are still on review but we'll land them soon. L1 is a likely milestone to have it ready in master. </div>
</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>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">Also, has there been any work on Exporting/Importing them through some defined format (tarball?) that doesn't depend on the artefact type?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div class="gmail_default" style="font-size:small">This one is not completely implemented: the design is ready (the spec had this feature from the very beginning) and a PoC was done. The final implementation is likely to happen in L cycle. </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>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">I've been talking with the Heat folks on starting a blueprint to allow heat templates to use relative URL's instead of absolute ones. That would allow a set of Heat templates to be
stored in one artefact in Glance.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div class="gmail_default" style="font-size:small">That's awesome. </div>
<div class="gmail_default" style="font-size:small">Also I'd consider allowing Heat to reference Templates by their artifact IDs in Glance, same as Nova does it for images. </div>
<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">
<div style="font-family:Times New Roman;color:#000000;font-size:16px">
<hr>
<div style="direction:ltr"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Alexander Tivelkov [<a href="mailto:ativelkov@mirantis.com" target="_blank">ativelkov@mirantis.com</a>]<br>
<b>Sent:</b> Thursday, May 28, 2015 4:46 AM
<div>
<div><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [new][app-catalog] App Catalog next steps<br>
</div>
</div>
</font><br>
</div>
<div>
<div>
<div></div>
<div>
<div dir="ltr">
<div style="font-size:small">Hi folks,</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">I believe that at least part of the filtering we are discussing here may be done at the client side if the client is sophisticated enough to be aware about the capabilities of the local cloud.</div>
<div style="font-size:small">And by "sophisticated client" I mean "Glance V3" (previously known as "Artifact Repository"), which may (and, in my vision, should) become the ultimate consumer of the app catalog on the cloud side.</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">Each asset type (currently Image, Murano Package, Heat template, more to come) should be implemented as Glance Artifact type (i.e. a plugin), and may define the required capabilities as its type specific metadata fields (for example,
Heat-template type may list plugins which are required to run this template; Murano-package type may set the minimum required version of Core library etc). The logic which is needed to validate this capabilities may be put into this type-specific plugin as
well. This custom logic method will gets executed when the artifact is being exported from app catalog into the particular cloud.</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">In this case the compatibility of particular artifact with particular cloud will be validated by that cloud itself when the app catalog is browsed. Also, if the cloud does not have support of some artifact types at all (e.g. does
not have Murano installed and thus cannot utilize Murano Packages), then it does not have the Murano plugin in its glance and thus will not be able to import murano-artifacts from the Catalog.</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">Hope this makes sense. </div>
<div style="font-size:small"><br>
</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div>
<div dir="ltr"><font size="2">--<br>
</font>
<div dir="ltr"><font size="2">Regards,<br>
Alexander Tivelkov</font></div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Thu, May 28, 2015 at 10:29 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">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On Wed, May 27, 2015 at 5:33 PM, 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"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On Wed, May 27, 2015 at 4:27 PM, Fox, Kevin M <span dir="ltr">
<<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:rgb(0,0,0);font-size:10pt">
I'd say, tools that utilize OpenStack, like the knife openstack plugin, are not something that you would probably go to the catalog to find. And also, the recipes that you would use with knife would not be specific to OpenStack in any way, so you would just
be duplicating the config management system's own catalog in the OpenStack catalog, which would be error prone. Duplicating all the chef recipes, and docker containers, puppet stuff, and ..... is a lot of work...<br>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>I am very much against duplicating things, including chef recipes that use the openstack plugin for knife. But we can still easily point to external resources from
<a href="http://apps.openstack.org" target="_blank">apps.openstack.org</a>. In fact we already do (<a href="http://apps.openstack.org/#tab=heat-templates&asset=Lattice" target="_blank">http://apps.openstack.org/#tab=heat-templates&asset=Lattice</a>).</div>
<span>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:rgb(0,0,0);font-size:10pt">
<br>
The vision I have for the Catalog (I can be totally wrong here, lets please discuss) is a place where users (non computer scientists) can visit after logging into their Cloud, pick some app of interest, hit launch, and optionally fill out a form. They then
have a running piece of software, provided by the greater OpenStack Community, that they can interact with, and their Cloud can bill them for. Think of it as the Apple App Store for OpenStack. Having a reliable set of deployment engines (Murano, Heat, whatever)
involved is critical to the experience I think. Having too many of them though will mean it will be rare to have a cloud that has all of them, restricting the utility of the catalog. Too much choice here may actually be a detriment.<br>
<br>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>calling this a catalog, which it sounds accurate, is confusing since keystone already has a catalog. Naming things is unfortunately a difficult problem.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>This is in itself turns into a really unfortunately usability issue for a number of reason; colliding namespaces that end users need to be aware of serves to generate confusion. Even the choices made naming things currently in use by OpenStack (I openly
admit Keystone is particularly bad in this light) have this issue. I would support a "catalog-like" name that limits confusion especially when it comes to conveying this information to the end users (not just deployers and operators). </div>
<div><br>
</div>
<div>I will reiterate Joe's statement: Naming things is unfortunately a difficult problem.</div>
<span>
<div> </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><br>
</div>
<div>I respectfully disagree with this vision. I mostly agree with the first part about it being somewhere users can go to find applications that can be quickly deployed on OpenStack (note all the gotchas that Monty described here). The part I disagree with
is about limiting the deployment engines to invented here. Even if we have 100 deployment engines on
<a href="http://apps.openstack.org" target="_blank">apps.openstack.org</a>, it would be very easy for a user to filter by the deployment engines they use so I do not agree with your concern about too many choices here being a detriment (after all isn't OpenStack
about choices?). </div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>++</div>
<div><br>
</div>
<div>We should be as inclusive as we can be. There are many cases of prior art where (as long as it's workable) we can do filtering (someone brought up the mobile app stores). Even if we want to be measured in ensuring the filtering works before opening the
flood gates, allowing alternate deployment engines is a good thing. It makes OpenStack more usable and more desirable as a platform</div>
<div>
<div>
<div> </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>
<div>Secondly IMHO the notion that 'if it wasn't invented here we shouldn't support it' [0] is a dangerous one that results on us constantly re-inventing the wheel while alienating the larger developer community by saying there solutions are no good, you should
use the OpenStack version of it.</div>
<div> </div>
<div><br>
</div>
<div>OpenStack isn't a single 'thing' it is a collection of 'things' and user's should be able to pick and choose which components they want and which components they want to get from elsewhere.</div>
<div><br>
</div>
<div>[0] <a href="http://en.wikipedia.org/wiki/Not_invented_here" target="_blank">
http://en.wikipedia.org/wiki/Not_invented_here</a><br>
</div>
<span>
<div><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:rgb(0,0,0);font-size:10pt">
If chef, or what ever other configuration management system became multitenant aware, and integrated into OpenStack and provided by the Cloud providers, then maybe it would fit into the app store vision?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>I am not sure why this matters? As a dependency you simply state chef, and either require users to provide it or tell them to use a chef heat template, glance image, etc.</div>
<div>
<div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:rgb(0,0,0);font-size:10pt">
<br>
Thanks,<br>
Kevin
<div style="font-family:'Times New Roman';color:rgb(0,0,0);font-size:16px">
<hr>
<div style="direction:ltr"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Joe Gordon [<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>]<br>
<b>Sent:</b> Wednesday, May 27, 2015 3:20 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<span><br>
<b>Subject:</b> Re: [openstack-dev] [new][app-catalog] App Catalog next steps<br>
</span></font><br>
</div>
<div></div>
<div>
<div dir="ltr"><br>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo <span dir="ltr">
<<a href="mailto:caedo@mirantis.com" target="_blank">caedo@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I want to start off by thanking everyone who joined us at the first<br>
working session in Vancouver, and those folks who have already started<br>
adding content to the app catalog. I was happy to see the enthusiasm<br>
and excitement, and am looking forward to working with all of you to<br>
build this into something that has a major impact on OpenStack<br>
adoption by making it easier for our end users to find and share the<br>
assets that run on our clouds.<br>
</blockquote>
<div><br>
</div>
<div>Great job. This is very exciting to see, I have been wanting something like this for some time now.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The catalog: <a href="http://apps.openstack.org" target="_blank">http://apps.openstack.org</a><br>
The repo: <a href="https://github.com/stackforge/apps-catalog" target="_blank">https://github.com/stackforge/apps-catalog</a><br>
The wiki: <a href="https://wiki.openstack.org/wiki/App-Catalog" target="_blank">https://wiki.openstack.org/wiki/App-Catalog</a><br>
<br>
Please join us via IRC at #openstack-app-catalog on freenode.<br>
<br>
Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox,<br>
Serg Melikyan.<br>
<br>
I’ve started a doodle poll to vote on the initial IRC meeting<br>
schedule, if you’re interested in helping improve and build up this<br>
catalog please vote for the day/time that works best and get involved!<br>
<a href="http://doodle.com/vf3husyn4bdkui8w" target="_blank">http://doodle.com/vf3husyn4bdkui8w</a><br>
<br>
At the summit we managed to get one planning session together. We<br>
captured that on etherpad[1], but I’d like to highlight here a few of<br>
the things we talked about working on together in the near term:<br>
<br>
-More information around asset dependencies (like clarifying<br>
requirements for Heat templates or Glance images for instance),<br>
potentially just by providing better guidance in what should be in the<br>
description and attributes sections.<br>
-With respect to the assets that are listed in the catalog, there’s a<br>
need to account for tagging, rating/scoring, and a way to have<br>
comments or a forum for each asset so potential users can interact<br>
outside of the gerrit review system.<br>
-Supporting more resource types (Sahara, Trove, Tosca, others)<br>
</blockquote>
<div><br>
</div>
<div>What about expanding the scope of the application catalog to any application that can run *on* OpenStack, versus the implied scope of applications that can be deployed *by* (heat, murano, etc.) OpenStack and *on* OpenStack services (nova, cinder etc.).
This would mean adding room for Ansible roles that provision openstack resources [0]. And more generally it would reinforce the point that there is no 'blessed' method of deploying applications on OpenStack, you can use tools developed specifically for OpenStack
or tools developed elsewhere.</div>
<div><br>
</div>
<div><br>
</div>
<div>[0] <a href="https://github.com/ansible/ansible-modules-core/blob/1f99382dfb395c1b993b2812122761371da1bad6/cloud/openstack/os_server.py" target="_blank">https://github.com/ansible/ansible-modules-core/blob/1f99382dfb395c1b993b2812122761371da1bad6/cloud/openstack/os_server.py</a></div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
-Discuss using glance artifact repository as the backend rather than<br>
flat YAML files<br>
-REST API, enable searching/sorting, this would ease native<br>
integration with other projects<br>
-Federated catalog support (top level catalog including contents from<br>
sub-catalogs)<br>
- I’ll be working with the OpenStack infra team to get the server and<br>
CI set up in their environment (though that work will not impact the<br>
catalog as it stands today).<br>
</blockquote>
<div><br>
</div>
<div>I am pleased to see moving this to OpenStack Infra is a high priority.</div>
<div><br>
</div>
<div>A quick nslookup of <a href="http://apps.openstack.org" target="_blank">http://apps.openstack.org</a> shows it us currently hosted on linode at <a href="http://nb-23-239-6-45.fremont.nodebalancer.linode.com/" target="_blank">http://nb-23-239-6-45.fremont.nodebalancer.linode.com/</a>.
And last I checked linode isn't OpenStack powered. <a href="http://apps.openstack.org" target="_blank">apps.openstack.org</a> is a great example of the type of application that should be easy to deploy with OpenStack, since as far as I can tell it just needs
a web server and that is it. So wearing my OpenStack developer hat on, why did you go with linode and not any one of the OpenStack based public clouds [1]? If OpenStack is not a good solution for workloads like this, then it would be great to know how what
needs work.</div>
<div> </div>
<div><br>
</div>
<div>[1] <a href="https://www.openstack.org/marketplace/public-clouds/" target="_blank">https://www.openstack.org/marketplace/public-clouds/</a></div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
There were a ton of great ideas that came up and it was clear there<br>
was WAY more to discuss than we could accomplish in one short session<br>
at the summit. I’m looking forward to continuing the conversation<br>
here on the mailing list, on IRC, and in Tokyo as well!<br>
<br>
[1] <a href="https://etherpad.openstack.org/p/YVR-app-catalog-plans" target="_blank">
https://etherpad.openstack.org/p/YVR-app-catalog-plans</a><br>
<br>
-Christopher<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</div>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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 Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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 Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</div>
</div>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</div></div></div>
</div>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>