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) <skand...@cisco.com> wrote: > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
