[openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS
Jay Pipes
jaypipes at gmail.com
Mon Oct 27 18:05:45 UTC 2014
Yup, can do! :)
-jay
On 10/27/2014 01:55 PM, Doug Wiegley wrote:
> Hi Jay,
>
> Let’s add that as an agenda item at our Weekly IRC meeting. Can you make
> this timeslot?
>
> https://wiki.openstack.org/wiki/Octavia#Meetings
>
>
> Thanks,
> Doug
>
>
> On 10/27/14, 11:27 AM, "Jay Pipes" <jaypipes at gmail.com> wrote:
>
>> Sorry for top-posting, but where can the API working group see the
>> proposed Octavia API specification or documentation? I'd love it if the
>> API WG could be involved in reviewing the public REST API.
>>
>> Best,
>> -jay
>>
>> On 10/27/2014 10:01 AM, Kyle Mestery wrote:
>>> On Sun, Oct 26, 2014 at 8: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.
>>>>
>>> I think we all know we want to spin these out, as Doug says we just
>>> need to have a plan around how we make that happen. I'm in agreement
>>> with Doug's sentiment above.
>>>
>>>>> 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.
>>>>
>>> Doug, can you document this on the etherpad for the "services spinout"
>>> [1]? I've added some brief text at the top on what the objective for
>>> this session is, but documenting more along the lines of what you have
>>> here would be good.
>>>
>>> Thanks,
>>> Kyle
>>>
>>> [1] https://etherpad.openstack.org/p/neutron-services
>>>
>>>> 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/8a0b7c1d64883c08286e4446e163f
>>>>>>> 1a6
>>>>>>> #.
>>>>>>> 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
>
More information about the OpenStack-dev
mailing list