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