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

Susanne Balle sleipnir012 at gmail.com
Wed Jun 11 15:57:59 UTC 2014


Do we know who has an opinion? If so maybe we can reach out to them
directly and ask them to comment.


On Tue, Jun 10, 2014 at 6:44 PM, Brandon Logan <brandon.logan at rackspace.com>
wrote:

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140611/4a5b789a/attachment.html>


More information about the OpenStack-dev mailing list