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

Kyle Mestery mestery at noironetworks.com
Thu Jun 5 14:26:59 UTC 2014


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



More information about the OpenStack-dev mailing list