[openstack-dev] [Neutron] Implementing new LBaaS API

Brandon Logan brandon.logan at RACKSPACE.COM
Tue Jun 10 19:38:45 UTC 2014


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:mestery at 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.logan at 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.logan at RACKSPACE.COM]
> >> Sent: Wednesday, June 04, 2014 2:18 PM
> >> To: openstack-dev at 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.logan at 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 at lists.openstack.org 
> >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> > _______________________________________________
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev at lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list