Open Stack

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