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?
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
