Got it. So we will be discussing this in the 2PM meeting today. Correct? Regards, Mandeep
On Mon, Oct 27, 2014 at 10:02 AM, Kyle Mestery <mest...@mestery.com> wrote: > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev