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