What was discussed at yesterday's Neutron core meeting?
On Tue, Jun 10, 2014 at 3: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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev