Open Stack

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