<div dir="ltr"><div>From a few chats I had on IRC it seems some of the teams that are now joining the load balancing effort are confident to be able to build a standalone, production-grade service for the juno release; also I read this email post [1], which points to the etherpad [2]</div>
<div><br></div><div>So, since I've been missing the lbaas meeting recently I probably wrongly deducted it was a done deal.</div><div><br></div><div>[1] <a href="http://lists.openstack.org/pipermail/openstack/2014-June/007677.html">http://lists.openstack.org/pipermail/openstack/2014-June/007677.html</a></div>
<div>[2] <a href="https://etherpad.openstack.org/p/LBaaS_project_name_vote">https://etherpad.openstack.org/p/LBaaS_project_name_vote</a><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 16 June 2014 15:54, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@noironetworks.com" target="_blank">mestery@noironetworks.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"><div class="">On Mon, Jun 16, 2014 at 2:27 AM, Eugene Nikanorov<br>
<<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>> wrote:<br>
> Salvatore,<br>
><br>
>> Also - since it seems to me that there is also consensus regarding having<br>
>> load balancing move away into a separate project<br>
> To me it seems that there was no such a consensus; core team members were<br>
> advocating keeping lbaas within neutron.<br>
><br>
</div>In the short term, yes. But longer term, we'll reevaluate the<br>
viability of moving LBaaS out of Neutron into it's own incubated<br>
project, likely under the "Networking" program.<br>
<br>
Thanks,<br>
Kyle<br>
<div class=""><div class="h5"><br>
> Thanks,<br>
> Eugene.<br>
><br>
><br>
> On Mon, Jun 16, 2014 at 2:23 AM, Brandon Logan <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>><br>
> wrote:<br>
>><br>
>> Thank you Salvatore for your feedback.<br>
>><br>
>> Comments in-line.<br>
>><br>
>> On Sun, 2014-06-15 at 23:26 +0200, Salvatore Orlando wrote:<br>
>> > Regarding the two approaches outlines in the top post, I found out<br>
>> > that the bullet "This is API versioning done the wrong way" appears in<br>
>> > both approaches.<br>
>> > Is this a mistake or intentional?<br>
>><br>
>> No it was intentional. In my opinion they are both the wrong way. It<br>
>> would be best to be able to do a version at the resource layer but we<br>
>> can't since lbaas is a part of Neutron and its versions is directly tied<br>
>> to Neutron's. Another possibility is to have the resource look like:<br>
>><br>
>> http(s)://neutron.endpoint/v2/lbaas/v2<br>
>><br>
>> This looks very odd to me though and sets a bad precedent. That is just<br>
>> my opinion though. So I wouldn't call this the right way either. Thus,<br>
>> I do not know of a "right" way to do this other than choosing the right<br>
>> "alternative" way.<br>
>><br>
>> ><br>
>> ><br>
>> > From what I gather, the most reasonable approach appears to be<br>
>> > starting with a clean slate, which means having a new API living side<br>
>> > by side with the old one.<br>
>> > I think the naming collision issues should probably be solved using<br>
>> > distinct namespaces for the two API (the old one has /v2/lbaas as a<br>
>> > URI prefix I think, I have hardly any idea about what namespace the<br>
>> > new one should have)<br>
>> ><br>
>><br>
>> I'm in agreement with you as well. The old one has /v2/lb as the prefix.<br>
>> I figured the new one could be /v2/lbaas which I think works out well.<br>
>><br>
>> Another thing to consider that I did not think about in my original<br>
>> message is that a whole new load balancing agent will have to be created<br>
>> as well since its code is written with the pool being the root object.<br>
>> So that should be taken into consideration. So to be perfectly clear,<br>
>> starting with a clean slate would involve the following:<br>
>><br>
>> 1. New loadbalancer extension<br>
>> 2. New loadbalancer plugin<br>
>> 3. New lbaas_agentscheduler extension<br>
>> 4. New agent_scheduler plugin.<br>
>><br>
>> Also, I don't believe doing this would allow the two to be deployed at<br>
>> the same time. I believe the setup.cfg file would have to be modified<br>
>> to point to the new plugins. I could be wrong about that though.<br>
>><br>
>> ><br>
>> > Finally, about deprecation - I see it's been agreed to deprecate the<br>
>> > current API in Juno.<br>
>> > I think this is not the right way of doing things. The limits of the<br>
>> > current API are pretty much universally agreed; on the other hand, it<br>
>> > is generally not advisable to deprecate an old API in favour of the<br>
>> > new one at the first iteration such API is published. My preferred<br>
>> > strategy would be to introduce the new API as experimental in the Juno<br>
>> > release, so that in can be evaluated, apply any feedback and consider<br>
>> > for promoting in K - and contextually deprecate the old API.<br>
>> ><br>
>> ><br>
>> > As there is quite a radical change between the old and the new model,<br>
>> > keeping the old API indefinitely is a maintenance burden we probably<br>
>> > can't afford, and I would therefore propose complete removal one<br>
>> > release cycle after deprecation. Also - since it seems to me that<br>
>> > there is also consensus regarding having load balancing move away into<br>
>> > a separate project so that it would not be tied anymore to the<br>
>> > networking program, the old API is pretty much just dead weight.<br>
>> ><br>
>> > Salvatore<br>
>><br>
>> Good idea on that. I'll bring this up with everyone at the hackathon<br>
>> this week if it is not already on the table.<br>
>><br>
>> Thanks again for your feedback.<br>
>><br>
>> Brandon<br>
>> ><br>
>> ><br>
>> > On 11 June 2014 18:01, Kyle Mestery <<a href="mailto:mestery@noironetworks.com">mestery@noironetworks.com</a>> wrote:<br>
>> > I spoke to Mark McClain about this yesterday, I'll see if I<br>
>> > can get<br>
>> > him to join the LBaaS team meeting tomorrow so between he and<br>
>> > I we can<br>
>> > close on this with the LBaaS team.<br>
>> ><br>
>> > On Wed, Jun 11, 2014 at 10:57 AM, Susanne Balle<br>
>> > <<a href="mailto:sleipnir012@gmail.com">sleipnir012@gmail.com</a>> wrote:<br>
>> > > Do we know who has an opinion? If so maybe we can reach out<br>
>> > to them directly<br>
>> > > and ask them to comment.<br>
>> > ><br>
>> > ><br>
>> > > On Tue, Jun 10, 2014 at 6:44 PM, Brandon Logan<br>
>> > <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>><br>
>> > > wrote:<br>
>> > >><br>
>> > >> Well we got a few opinions, but not enough understanding of<br>
>> > the two<br>
>> > >> options to make an informed decision. It was requested<br>
>> > that the core<br>
>> > >> reviewers respond to this thread with their opinions.<br>
>> > >><br>
>> > >> Thanks,<br>
>> > >> Brandon<br>
>> > >><br>
>> > >> On Tue, 2014-06-10 at 13:22 -0700, Stephen Balukoff wrote:<br>
>> > >> > Yep, I'd like to know here, too-- as knowing the answer<br>
>> > to this<br>
>> > >> > unblocks implementation work for us.<br>
>> > >> ><br>
>> > >> ><br>
>> > >> > On Tue, Jun 10, 2014 at 12:38 PM, Brandon Logan<br>
>> > >> > <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
>> > >> > Any core neutron people have a chance to give<br>
>> > their opinions<br>
>> > >> > on this<br>
>> > >> > yet?<br>
>> > >> ><br>
>> > >> > Thanks,<br>
>> > >> > Brandon<br>
>> > >> ><br>
>> > >> > On Thu, 2014-06-05 at 15:28 +0000, Buraschi,<br>
>> > Andres wrote:<br>
>> > >> > > Thanks, Kyle. Great.<br>
>> > >> > ><br>
>> > >> > > -----Original Message-----<br>
>> > >> > > From: Kyle Mestery<br>
>> > [mailto:<a href="mailto:mestery@noironetworks.com">mestery@noironetworks.com</a>]<br>
>> > >> > > Sent: Thursday, June 05, 2014 11:27 AM<br>
>> > >> > > To: OpenStack Development Mailing List (not for<br>
>> > usage<br>
>> > >> > questions)<br>
>> > >> > > Subject: Re: [openstack-dev] [Neutron]<br>
>> > Implementing new<br>
>> > >> > LBaaS API<br>
>> > >> > ><br>
>> > >> > > On Wed, Jun 4, 2014 at 4:27 PM, Brandon Logan<br>
>> > >> > <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
>> > >> > > > Hi Andres,<br>
>> > >> > > > I've assumed (and we know how assumptions<br>
>> > work) that the<br>
>> > >> > deprecation<br>
>> > >> > > > would take place in Juno and after a cyle or<br>
>> > two it would<br>
>> > >> > totally be<br>
>> > >> > > > removed from the code. Even if #1 is the way<br>
>> > to go, the<br>
>> > >> > old /vips<br>
>> > >> > > > resource would be deprecated in favor<br>
>> > of /loadbalancers<br>
>> > >> > and /listeners.<br>
>> > >> > > ><br>
>> > >> > > > I agree #2 is cleaner, but I don't want to<br>
>> > start on an<br>
>> > >> > implementation<br>
>> > >> > > > (though I kind of already have) that will<br>
>> > fail to be<br>
>> > >> > merged in because<br>
>> > >> > > > of the strategy. The strategies are pretty<br>
>> > different so<br>
>> > >> > one needs to<br>
>> > >> > > > be decided on.<br>
>> > >> > > ><br>
>> > >> > > > As for where LBaaS is intended to end up, I<br>
>> > don't want to<br>
>> > >> > speak for<br>
>> > >> > > > Kyle, so this is my understanding; It will<br>
>> > end up outside<br>
>> > >> > of the<br>
>> > >> > > > Neutron code base but Neutron and LBaaS and<br>
>> > other services<br>
>> > >> > will all<br>
>> > >> > > > fall under a Networking (or Network)<br>
>> > program. That is my<br>
>> > >> > > > understanding and I could be totally wrong.<br>
>> > >> > > ><br>
>> > >> > > That's my understanding as well, I think<br>
>> > Brandon worded it<br>
>> > >> > perfectly.<br>
>> > >> > ><br>
>> > >> > > > Thanks,<br>
>> > >> > > > Brandon<br>
>> > >> > > ><br>
>> > >> > > > On Wed, 2014-06-04 at 20:30 +0000, Buraschi,<br>
>> > Andres wrote:<br>
>> > >> > > >> Hi Brandon, hi Kyle!<br>
>> > >> > > >> I'm a bit confused about the deprecation<br>
>> > (btw, thanks for<br>
>> > >> > sending this Brandon!), as I (wrongly) assumed #1<br>
>> > would be the<br>
>> > >> > chosen path for the new API implementation. I<br>
>> > understand the<br>
>> > >> > proposal and #2 sounds actually cleaner.<br>
>> > >> > > >><br>
>> > >> > > >> Just out of curiosity, Kyle, where is LBaaS<br>
>> > functionality<br>
>> > >> > intended to end up, if long-term plans are to<br>
>> > remove it from<br>
>> > >> > Neutron?<br>
>> > >> > > >><br>
>> > >> > > >> (Nit question, I must clarify)<br>
>> > >> > > >><br>
>> > >> > > >> Thank you!<br>
>> > >> > > >> Andres<br>
>> > >> > > >><br>
>> > >> > > >> -----Original Message-----<br>
>> > >> > > >> From: Brandon Logan<br>
>> > [mailto:<a href="mailto:brandon.logan@RACKSPACE.COM">brandon.logan@RACKSPACE.COM</a>]<br>
>> > >> > > >> Sent: Wednesday, June 04, 2014 2:18 PM<br>
>> > >> > > >> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>> > >> > > >> Subject: Re: [openstack-dev] [Neutron]<br>
>> > Implementing new<br>
>> > >> > LBaaS API<br>
>> > >> > > >><br>
>> > >> > > >> Thanks for your feedback Kyle. I will be at<br>
>> > that meeting<br>
>> > >> > on Monday.<br>
>> > >> > > >><br>
>> > >> > > >> Thanks,<br>
>> > >> > > >> Brandon<br>
>> > >> > > >><br>
>> > >> > > >> On Wed, 2014-06-04 at 11:54 -0500, Kyle<br>
>> > Mestery wrote:<br>
>> > >> > > >> > On Tue, Jun 3, 2014 at 3:01 PM, Brandon<br>
>> > Logan<br>
>> > >> > > >> > <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
>> > >> > > >> > > This is an LBaaS topic bud I'd like to<br>
>> > get some<br>
>> > >> > Neutron Core<br>
>> > >> > > >> > > members to give their opinions on this<br>
>> > matter so I've<br>
>> > >> > just<br>
>> > >> > > >> > > directed this to Neutron proper.<br>
>> > >> > > >> > ><br>
>> > >> > > >> > > The design for the new API and object<br>
>> > model for LBaaS<br>
>> > >> > needs to be<br>
>> > >> > > >> > > locked down before the hackathon in a<br>
>> > couple of weeks<br>
>> > >> > and there<br>
>> > >> > > >> > > are some questions that need answered.<br>
>> > This is<br>
>> > >> > pretty urgent to<br>
>> > >> > > >> > > come on to a decision on and to get a<br>
>> > clear strategy<br>
>> > >> > defined so<br>
>> > >> > > >> > > we can actually do real code during the<br>
>> > hackathon<br>
>> > >> > instead of<br>
>> > >> > > >> > > wasting some of that valuable time<br>
>> > discussing this.<br>
>> > >> > > >> > ><br>
>> > >> > > >> > ><br>
>> > >> > > >> > > Implementation must be backwards<br>
>> > compatible<br>
>> > >> > > >> > ><br>
>> > >> > > >> > > There are 2 ways that have come up on<br>
>> > how to do this:<br>
>> > >> > > >> > ><br>
>> > >> > > >> > > 1) New API and object model are created<br>
>> > in the same<br>
>> > >> > extension and<br>
>> > >> > > >> > > plugin as the old. Any API requests<br>
>> > structured for<br>
>> > >> > the old API<br>
>> > >> > > >> > > will be translated/adapted to the into<br>
>> > the new object<br>
>> > >> > model.<br>
>> > >> > > >> > > PROS:<br>
>> > >> > > >> > > -Only one extension and plugin<br>
>> > >> > > >> > > -Mostly true backwards compatibility -Do<br>
>> > not have to<br>
>> > >> > rename<br>
>> > >> > > >> > > unchanged resources and models<br>
>> > >> > > >> > > CONS:<br>
>> > >> > > >> > > -May end up being confusing to an<br>
>> > end-user.<br>
>> > >> > > >> > > -Separation of old api and new api is<br>
>> > less clear<br>
>> > >> > -Deprecating and<br>
>> > >> > > >> > > removing old api and object model will<br>
>> > take a bit<br>
>> > >> > more work -This<br>
>> > >> > > >> > > is basically API versioning the wrong<br>
>> > way<br>
>> > >> > > >> > ><br>
>> > >> > > >> > > 2) A new extension and plugin are<br>
>> > created for the new<br>
>> > >> > API and<br>
>> > >> > > >> > > object model. Each API would live side<br>
>> > by side. New<br>
>> > >> > API would<br>
>> > >> > > >> > > need to have different names for<br>
>> > resources and object<br>
>> > >> > models from<br>
>> > >> > > >> > > Old API resources and object models.<br>
>> > >> > > >> > > PROS:<br>
>> > >> > > >> > > -Clean demarcation point between old and<br>
>> > new -No<br>
>> > >> > translation<br>
>> > >> > > >> > > layer needed -Do not need to modify<br>
>> > existing API and<br>
>> > >> > object<br>
>> > >> > > >> > > model, no new bugs -Drivers do not need<br>
>> > to be<br>
>> > >> > immediately<br>
>> > >> > > >> > > modified -Easy to deprecate and remove<br>
>> > old API and<br>
>> > >> > object model<br>
>> > >> > > >> > > later<br>
>> > >> > > >> > > CONS:<br>
>> > >> > > >> > > -Separate extensions and object model<br>
>> > will be<br>
>> > >> > confusing to<br>
>> > >> > > >> > > end-users -Code reuse by copy paste<br>
>> > since old<br>
>> > >> > extension and<br>
>> > >> > > >> > > plugin will be deprecated and removed.<br>
>> > >> > > >> > > -This is basically API versioning the<br>
>> > wrong way<br>
>> > >> > > >> > ><br>
>> > >> > > >> > > Now if #2 is chosen to be feasible and<br>
>> > acceptable<br>
>> > >> > then there are<br>
>> > >> > > >> > > a number of ways to actually do that. I<br>
>> > won't bring<br>
>> > >> > those up<br>
>> > >> > > >> > > until a clear decision is made on which<br>
>> > strategy<br>
>> > >> > above is the most acceptable.<br>
>> > >> > > >> > ><br>
>> > >> > > >> > Thanks for sending this out Brandon. I'm<br>
>> > in favor of<br>
>> > >> > option #2<br>
>> > >> > > >> > above, especially considering the<br>
>> > long-term plans to<br>
>> > >> > remove LBaaS<br>
>> > >> > > >> > from Neutron. That approach will help the<br>
>> > eventual end<br>
>> > >> > goal there.<br>
>> > >> > > >> > I am also curious on what others think,<br>
>> > and to this<br>
>> > >> > end, I've added<br>
>> > >> > > >> > this as an agenda item for the team<br>
>> > meeting next<br>
>> > >> > Monday. Brandon,<br>
>> > >> > > >> > it would be great to get you there for the<br>
>> > part of the<br>
>> > >> > meeting<br>
>> > >> > > >> > where we'll discuss this.<br>
>> > >> > > >> ><br>
>> > >> > > >> > Thanks!<br>
>> > >> > > >> > Kyle<br>
>> > >> > > >> ><br>
>> > >> > > >> > > Thanks,<br>
>> > >> > > >> > > Brandon<br>
>> > >> > > >> > ><br>
>> > >> > > >> > ><br>
>> > >> > > >> > ><br>
>> > >> > > >> > ><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>
>> > >> > > >> > ><br>
>> > >> ><br>
>> > >> ><br>
>> ><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>
>> > >> > > >> ><br>
>> > >> ><br>
>> > >> ><br>
>> ><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>
>> > >> > > >><br>
>> > >> ><br>
>> > >> ><br>
>> ><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>
>> > >> > > >><br>
>> > >> ><br>
>> > >> ><br>
>> ><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>
>> > >> > > ><br>
>> > >> ><br>
>> > >> ><br>
>> ><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>
>> > >> > > OpenStack-dev mailing list<br>
>> > >> > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > >> > ><br>
>> > >> ><br>
>> > >> ><br>
>> ><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>
>> > >> > > OpenStack-dev mailing list<br>
>> > >> > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > >> > ><br>
>> > >> ><br>
>> > >> ><br>
>> ><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>
>> > >> > OpenStack-dev mailing list<br>
>> > >> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > >> ><br>
>> > >> ><br>
>> ><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>
>> > >> > --<br>
>> > >> > Stephen Balukoff<br>
>> > >> > Blue Box Group, LLC<br>
>> > >> > (800)613-4305 x807<br>
>> > >> > _______________________________________________<br>
>> > >> > OpenStack-dev mailing list<br>
>> > >> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > >> ><br>
>> ><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>
>> > >> OpenStack-dev mailing list<br>
>> > >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > >><br>
>> ><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>
>> > ><br>
>> ><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>
>> ><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>
>> 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>
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></div></div>