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