[openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

Kyle Mestery mestery at mestery.com
Mon Oct 27 17:02:05 UTC 2014


On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami <dhami at noironetworks.com> wrote:
> Hi Kyle:
>
> Are you scheduling an on-demand meeting, or are you proposing that the
> agenda for next neutron meeting include this as an on-demand item?
>
Per my email to the list recently [1], the weekly rotating Neutron
meeting is now an on-demand agenda, rather than a rollup of sub-team
status. I'm saying this particular topic (advanced services spinout)
will be discussed in Paris, and it's worth adding it to the weekly
Neutron meeting [2] agenda in the on-demand section. This is a pretty
large topic with many interested parties, thus the attention in the
broader neutron meeting.

Thanks,
Kyle

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/048328.html
[2] https://wiki.openstack.org/wiki/Network/Meetings

> Regards,
> Mandeep
>
>
> On Mon, Oct 27, 2014 at 6:56 AM, Kyle Mestery <mestery at mestery.com> wrote:
>>
>> On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
>> <sumitnaiksatam at gmail.com> wrote:
>> > Several people have been requesting that we resume the Advanced
>> > Services' meetings [1] to discuss some of the topics being mentioned
>> > in this thread. Perhaps it might help people to have a focussed
>> > discussion on the topic of "advanced services' spin-out" prior to the
>> > design summit session [2] in Paris. So I propose that we resume our
>> > weekly IRC meetings starting this Wednesday (Oct 29th), 17.30 UTC on
>> > #openstack-meeting-3.
>> >
>> Given how important this is to Neutron in general, I would prefer NOT
>> to see this discussed in the Advanced Services meeting, but rather in
>> the regular Neutron meeting. These are the types of things which need
>> broader oversight and involvement. Lets please discuss this in the
>> regular Neutron meeting, which is an on-demand meeting format, rather
>> than in a sub-team meeting.
>>
>> > Thanks,
>> > ~Sumit.
>> >
>> > [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
>> > [2]
>> > http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y
>> >
>> > On Sun, Oct 26, 2014 at 7:55 PM, Sridar Kandaswamy (skandasw)
>> > <skandasw at cisco.com> wrote:
>> >> Hi Doug:
>> >>
>> >> On 10/26/14, 6:01 PM, "Doug Wiegley" <dougw at a10networks.com> wrote:
>> >>
>> >>>Hi Brandon,
>> >>>
>> >>>> 4. I brought this up now so that we can decide whether we want to
>> >>>> discuss it at the advanced services spin out session.  I don't see
>> >>>> the
>> >>>> harm in opinions being discussed before the summit, during the
>> >>>> summit,
>> >>>> and more thoroughly after the summit.
>> >>>
>> >>>I agree with this sentiment.  I¹d just like to pull-up to the decision
>> >>>level, and if we can get some consensus on how we move forward, we can
>> >>>bring a concrete plan to the summit instead of 40 minutes of Kumbaya.
>> >>> We
>> >>>love each other.  Check.  Things are going to change sometime.  Check.
>> >>> We
>> >>>might spin-out someday.  Check.  Now, let¹s jump to the interesting
>> >>> part.
>> >>>
>> >>>> 3. The main reason a spin out makes sense from Neutron is that the
>> >>>> scope
>> >>>> for Neutron is too large for the attention advances services needs
>> >>>> from
>> >>>> the Neutron Core.  If all of advanced services spins out, I see that
>> >>>
>> >>>There is merit here, but consider the sorts of things that an advanced
>> >>>services framework should be doing:
>> >>>
>> >>>- plugging into neutron ports, with all manner of topologies
>> >>>- service VM handling
>> >>>- plugging into nova-network
>> >>>- service chaining
>> >>>- applying things like security groups to services
>> >>>
>> >>>Š this is all stuff that Octavia is talking about implementing itself
>> >>> in a
>> >>>basically defensive manner, instead of leveraging other work.  And
>> >>> there
>> >>>are specific reasons for that.  But, maybe we can at least take steps
>> >>> to
>> >>>not be incompatible about it.  Or maybe there is a hierarchy of Neutron
>> >>> ->
>> >>>Services -> LB, where we¹re still spun out, but not doing it in a way
>> >>> that
>> >>>we have to re-implement the world all the time.  It¹s at least worth a
>> >>>conversation or three.
>> >>
>> >> In total agreement and I have heard these sentiments in multiple
>> >> conversations across multiple players.
>> >> It would be really fruitful to have a constructive conversation on this
>> >> across the services, and there are
>> >> enough similar issues to make this worthwhile.
>> >>
>> >> Thanks
>> >>
>> >> Sridar
>> >>
>> >>>
>> >>>Thanks,
>> >>>Doug
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>On 10/26/14, 6:35 PM, "Brandon Logan" <brandon.logan at RACKSPACE.COM>
>> >>> wrote:
>> >>>
>> >>>>Good questions Doug.  My answers are as follows:
>> >>>>
>> >>>>1. Yes
>> >>>>2. Some time after Kilo (same as I don't know when)
>> >>>>3. The main reason a spin out makes sense from Neutron is that the
>> >>>> scope
>> >>>>for Neutron is too large for the attention advances services needs
>> >>>> from
>> >>>>the Neutron Core.  If all of advanced services spins out, I see that
>> >>>>repeating itself within an advanced services project.  More and more
>> >>>>"advanced services" will get added in and the scope will become too
>> >>>>large.  There would definitely be benefits to it though, but I think
>> >>>> we
>> >>>>would end up being right where we are today.
>> >>>>4. I brought this up now so that we can decide whether we want to
>> >>>>discuss it at the advanced services spin out session.  I don't see the
>> >>>>harm in opinions being discussed before the summit, during the summit,
>> >>>>and more thoroughly after the summit.
>> >>>>
>> >>>>Yes the brunt of the time will not be spent on the API, but since it
>> >>>>seemed like an opportunity to kill two birds with one stone, I figured
>> >>>>it warranted a discussion.
>> >>>>
>> >>>>Thanks,
>> >>>>Brandon
>> >>>>
>> >>>>On Sun, 2014-10-26 at 23:15 +0000, Doug Wiegley wrote:
>> >>>>> Hi all,
>> >>>>>
>> >>>>> Before we get into the details of which API goes where, I¹d like to
>> >>>>> see
>> >>>>>us
>> >>>>> answer the questions of:
>> >>>>>
>> >>>>> 1. Are we spinning out?
>> >>>>> 2. When?
>> >>>>> 3. With or without the rest of advanced services?
>> >>>>> 4. Do we want to wait until we (the royal ³we² of ³the Neutron
>> >>>>> team²)
>> >>>>>have
>> >>>>> had the Paris summit discussions on vendor split-out and adv.
>> >>>>> services
>> >>>>> spinout before we answer those questions?  (Yes, that question is
>> >>>>>leading.)
>> >>>>>
>> >>>>> To me, the ³where does the API live² is an implementation detail,
>> >>>>> and
>> >>>>>not
>> >>>>> where the time will need to be spent.
>> >>>>>
>> >>>>> For the record, my answers are:
>> >>>>>
>> >>>>> 1. Yes.
>> >>>>> 2. I don¹t know.
>> >>>>> 3. I don¹t know; this needs some serious discussion.
>> >>>>> 4. Yes.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> doug
>> >>>>>
>> >>>>> On 10/24/14, 3:47 PM, "Brandon Logan" <brandon.logan at RACKSPACE.COM>
>> >>>>>wrote:
>> >>>>>
>> >>>>> >With the recent talk about advanced services spinning out of
>> >>>>> > Neutron,
>> >>>>> >and the fact most of the LBaaS community has wanted LBaaS to spin
>> >>>>> > out
>> >>>>>of
>> >>>>> >Neutron, I wanted to bring up a possibility and gauge interest and
>> >>>>> >opinion on this possibility.
>> >>>>> >
>> >>>>> >Octavia is going to (and has) an API.  The current thinking is that
>> >>>>> > an
>> >>>>> >Octavia driver will be created in Neutron LBaaS that will make a
>> >>>>> >requests to the Octavia API.  When LBaaS spins out of Neutron, it
>> >>>>> > will
>> >>>>> >need a standalone API.  Octavia's API seems to be a good solution
>> >>>>> > to
>> >>>>> >this.  It will support vendor drivers much like the current Neutron
>> >>>>> >LBaaS does.  It has a similar API as Neutron LBaaS v2, but its not
>> >>>>> > an
>> >>>>> >exact duplicate.  Octavia will be growing more mature in stackforge
>> >>>>> > at
>> >>>>>a
>> >>>>> >higher velocity than an Openstack project, so I expect by the time
>> >>>>>Kilo
>> >>>>> >comes around it's API will be very mature.
>> >>>>> >
>> >>>>> >Octavia's API doesn't have to be called Octavia either.  It can be
>> >>>>> >separated out and it can be called Openstack LBaaS, and the rest of
>> >>>>> >Octavia (the actual brains of it) will just be another driver to
>> >>>>> >Openstack LBaaS, which would retain the Octavia name.
>> >>>>> >
>> >>>>> >This is my PROS and CONS list to using Octavia's API as the spun
>> >>>>> > out
>> >>>>> >LBaaS:
>> >>>>> >
>> >>>>> >PROS
>> >>>>> >1. Time will need to be spent on a spun out LBaaS's API anyway.
>> >>>>>Octavia
>> >>>>> >will already have this done.
>> >>>>> >2. Most of the same people working on Octavia have worked on
>> >>>>> > Neutron
>> >>>>> >LBaaS v2.
>> >>>>> >3. It's out of Neutron faster, which is good for Neutron and LBaaS.
>> >>>>> >
>> >>>>> >CONS
>> >>>>> >1. The Octavia API is dissimilar enough from Neutron LBaaS v2 to be
>> >>>>>yet
>> >>>>> >another version of an LBaaS API.
>> >>>>> >2. The Octavia API will also have a separate Operator API which
>> >>>>> > will
>> >>>>> >most likely only work with Octavia, not any vendors.
>> >>>>> >
>> >>>>> >The CONS are easily solvable, and IMHO the PROS greatly outweigh
>> >>>>> > the
>> >>>>> >CONS.
>> >>>>> >
>> >>>>> >This is just my opinion though and I'd like to hear back from as
>> >>>>> > many
>> >>>>>as
>> >>>>> >possible.  Add on to the PROS and CONS if wanted.
>> >>>>> >
>> >>>>> >If it is direction we can agree on going then we can add as a
>> >>>>> > talking
>> >>>>> >point in the advanced services spin out meeting:
>> >>>>> >
>> >>>>>
>>
>> >>>>>> >>>>>>http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a
>> >>>>>>6
>> >>>>>>#.
>> >>>>> >VEq66HWx3UY
>> >>>>> >
>> >>>>> >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
>



More information about the OpenStack-dev mailing list