[openstack-dev] [Neutron] Implementing new LBaaS API
Brandon Logan
brandon.logan at RACKSPACE.COM
Tue Jun 10 22:44:37 UTC 2014
Well we got a few opinions, but not enough understanding of the two
options to make an informed decision. It was requested that the core
reviewers respond to this thread with their opinions.
Thanks,
Brandon
On Tue, 2014-06-10 at 13:22 -0700, Stephen Balukoff wrote:
> Yep, I'd like to know here, too-- as knowing the answer to this
> unblocks implementation work for us.
>
>
> On Tue, Jun 10, 2014 at 12:38 PM, Brandon Logan
> <brandon.logan at rackspace.com> wrote:
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
> _______________________________________________
> 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