Hi Doug: On 10/26/14, 6:01 PM, "Doug Wiegley" <do...@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.lo...@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.lo...@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@lists.openstack.org >>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>_______________________________________________ >>OpenStack-dev mailing list >>OpenStack-dev@lists.openstack.org >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev