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

Kyle Mestery mestery at noironetworks.com
Mon Jun 16 13:54:40 UTC 2014


On Mon, Jun 16, 2014 at 2:27 AM, Eugene Nikanorov
<enikanorov at mirantis.com> wrote:
> Salvatore,
>
>> Also - since it seems to me that there is also consensus regarding having
>> load balancing move away into a separate project
> To me it seems that there was no such a consensus; core team members were
> advocating keeping lbaas within neutron.
>
In the short term, yes. But longer term, we'll reevaluate the
viability of moving LBaaS out of Neutron into it's own incubated
project, likely under the "Networking" program.

Thanks,
Kyle

> Thanks,
> Eugene.
>
>
> On Mon, Jun 16, 2014 at 2:23 AM, Brandon Logan <brandon.logan at rackspace.com>
> wrote:
>>
>> Thank you Salvatore for your feedback.
>>
>> Comments in-line.
>>
>> On Sun, 2014-06-15 at 23:26 +0200, Salvatore Orlando wrote:
>> > Regarding the two approaches outlines in the top post, I found out
>> > that the bullet "This is API versioning done the wrong way" appears in
>> > both approaches.
>> > Is this a mistake or intentional?
>>
>> No it was intentional.  In my opinion they are both the wrong way.  It
>> would be best to be able to do a version at the resource layer but we
>> can't since lbaas is a part of Neutron and its versions is directly tied
>> to Neutron's.  Another possibility is to have the resource look like:
>>
>> http(s)://neutron.endpoint/v2/lbaas/v2
>>
>> This looks very odd to me though and sets a bad precedent.  That is just
>> my opinion though.  So I wouldn't call this the right way either.  Thus,
>> I do not know of a "right" way to do this other than choosing the right
>> "alternative" way.
>>
>> >
>> >
>> > From what I gather, the most reasonable approach appears to be
>> > starting with a clean slate, which means having a new API living side
>> > by side with the old one.
>> > I think the naming collision issues should probably be solved using
>> > distinct namespaces for the two API (the old one has /v2/lbaas as a
>> > URI prefix I think, I have hardly any idea about what namespace the
>> > new one should have)
>> >
>>
>> I'm in agreement with you as well. The old one has /v2/lb as the prefix.
>> I figured the new one could be /v2/lbaas which I think works out well.
>>
>> Another thing to consider that I did not think about in my original
>> message is that a whole new load balancing agent will have to be created
>> as well since its code is written with the pool being the root object.
>> So that should be taken into consideration.  So to be perfectly clear,
>> starting with a clean slate would involve the following:
>>
>> 1. New loadbalancer extension
>> 2. New loadbalancer plugin
>> 3. New lbaas_agentscheduler extension
>> 4. New agent_scheduler plugin.
>>
>> Also, I don't believe doing this would allow the two to be deployed at
>> the same time.  I believe the setup.cfg file would have to be modified
>> to point to the new plugins.  I could be wrong about that though.
>>
>> >
>> > Finally, about deprecation - I see it's been agreed to deprecate the
>> > current API in Juno.
>> > I think this is not the right way of doing things. The limits of the
>> > current API are pretty much universally agreed; on the other hand, it
>> > is generally not advisable to deprecate an old API in favour of the
>> > new one at the first iteration such API is published. My preferred
>> > strategy would be to introduce the new API as experimental in the Juno
>> > release, so that in can be evaluated, apply any feedback and consider
>> > for promoting in K - and contextually deprecate the old API.
>> >
>> >
>> > As there is quite a radical change between the old and the new model,
>> > keeping the old API indefinitely is a maintenance burden we probably
>> > can't afford, and I would therefore propose complete removal one
>> > release cycle after deprecation. Also - since it seems to me that
>> > there is also consensus regarding having load balancing move away into
>> > a separate project so that it would not be tied anymore to the
>> > networking program, the old API is pretty much just dead weight.
>> >
>> > Salvatore
>>
>> Good idea on that.  I'll bring this up with everyone at the hackathon
>> this week if it is not already on the table.
>>
>> Thanks again for your feedback.
>>
>> Brandon
>> >
>> >
>> > On 11 June 2014 18:01, Kyle Mestery <mestery at noironetworks.com> wrote:
>> >         I spoke to Mark McClain about this yesterday, I'll see if I
>> >         can get
>> >         him to join the LBaaS team meeting tomorrow so between he and
>> >         I we can
>> >         close on this with the LBaaS team.
>> >
>> >         On Wed, Jun 11, 2014 at 10:57 AM, Susanne Balle
>> >         <sleipnir012 at gmail.com> wrote:
>> >         > 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
>> >         >
>> >         >
>> >         >
>> >         > _______________________________________________
>> >         > 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