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