Open Stack

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