On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami <dh...@noironetworks.com> wrote: > Hi Kyle: > > Are you scheduling an on-demand meeting, or are you proposing that the > agenda for next neutron meeting include this as an on-demand item? > Per my email to the list recently [1], the weekly rotating Neutron meeting is now an on-demand agenda, rather than a rollup of sub-team status. I'm saying this particular topic (advanced services spinout) will be discussed in Paris, and it's worth adding it to the weekly Neutron meeting [2] agenda in the on-demand section. This is a pretty large topic with many interested parties, thus the attention in the broader neutron meeting.
Thanks, Kyle [1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/048328.html [2] https://wiki.openstack.org/wiki/Network/Meetings > Regards, > Mandeep > > > On Mon, Oct 27, 2014 at 6:56 AM, Kyle Mestery <mest...@mestery.com> wrote: >> >> On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam >> <sumitnaiksa...@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) >> > <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 >> >> _______________________________________________ >> 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
