[openstack-dev] [Neutron] Implementing new LBaaS API
Kyle Mestery
mestery at noironetworks.com
Wed Jun 11 16:01:05 UTC 2014
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
>
More information about the OpenStack-dev
mailing list