Open Stack

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