Open Stack

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.

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