Open Stack

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