Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting
Hi, Just to be clear: We all think the incubator is a great idea and if some things are ironed out will be a good way to onboard new projects to Neutron. What bothers me is the timing. Without warning we were put in an incubator in the span of like 8 days. This makes it difficult to plan and adds unnecessary uncertainty. Who is guaranteeing that if I tell my management LBaaS v2 will be in Kilo that nobody will throw a wrench in five months time? What I like to see from the Neutron Core team is timely communication with proper transition plans: For example if there is a change in how things are done it should be implemented at the beginning of a cycle and projects started before the change should have a grace period where things are done the old way. I understand that some things might have to be retroactively but that should be kept to a minimum - I also want to reiterate that we are quite happy and pleased with the Neutron core team -- To Doug's argument about displacing LBaaS v1: I am convinced that the reference implementation/driver absolutely belongs into the incubator. It is frankly unusable. The API itself has its problems but I agree for people with hardware load balancers there might be some value. However, the mechanics of Neutron (we need an open source reference driver) leave us with basically two bad choices: Leave an unusable driver in Neutron or pull everything out. I am not sure what the lesser evil is but from an operator perspective I am happy to just toss the whole thing into the incubator. Thanks, German -Original Message- From: Doug Wiegley [mailto:do...@a10networks.com] Sent: Monday, August 18, 2014 7:05 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting So now that is two people on this thread that are treating moving lbaas v1 to incubator as an of course, duh kind of thing. I do not agree. Insofar as most of neutron advanced services is feeling the velocity and maturity pain, sure. But lbaas v2 has NO dependency on v1, it's stable, been shipping for several cycles, has users. it would be odd to just up and disappear in Juno. Seems to make more sense to let it continue in maintenance, likely deprecated in Kilo, and be removed as part of a normal lifecycle. v2 is nowhere near as far along, partly because we jumped through some extra hoops, but whatever, they are not in identical situations. Thanks, Doug On 8/18/14, 7:49 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: I agree pretty strongly with Brandon's and Doug's comments as well. And I did want to clarify that I certainly don't hate the Neutron cores either. I feel like we (those working on Neutron LBaaS and the Cores) made commitments to each other both at the Atlanta summit and the mid-cycle hackathon, including taking on additional work we otherwise wouldn't have done in order to work with the Neutron team in good faith. I feel like we upheld our end of the deal, but without getting the reviews we need to get into Juno, and with LBaaS becoming the poster child (or proof of concept, or guinea pig, depending on your level of cynicism) for projects that should go into Neutron Incubator... well, here we are about to hit Juno-3 and there's essentially zero chance we're going to get in. All that is to say, I think the cores we've been working with embarked on this in good faith, but unexpected happenings in the Neutron community have necessitated the events as they are happening. I think I understand *why* things have happened as they have, but I can't help but feel like our team was betrayed here. And it's certainly not going to be any easier to convince our bosses that our time working on Neutron LBaaS over the last few months was well spent when the features and changes we need are no closer to becoming part of the official, accepted code base. (Heck, if Brandon is the voice of Optimism in our defacto team, then you can call me the voice of Skepticism in it: It's also conceivable that with the extra complication of neutron-incubator graduation being worked through, it is likely that we will not see our changes get into Kilo either!) I do hope that they take our previously voiced concerns about neutron-incubator very seriously (particularly the ones about moving Neutron LBaaS v1 into incubator, and taking meaningful, tangible steps to solve the core reviewer bandwidth problem that I think is the *real* reason it takes so long to get major changes into Neutron.) At this time, though, I feel like prudence demands we spend time making Octavia happen-- after all, we can only go through so many cycles where we effectively have nothing to show for our work before we'll all be out of our jobs. :/ On joining the weekly meetings and otherwise contributing: We'd love to have you attend Salvatore! If you (or anyone else interested) are free at 20:00 UTC
Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting
Thanks for the summary Trevor. On 08/18/2014 01:25 PM, Trevor Vardeman wrote: 1) Discuss future of Octavia in light of Neutron-incubator project proposal. a) There are many problems with Neutron-Incubator as currently described Let's be specific, enumerate the problems and address them, please. And keeping in mind that Neutron code is *still* bashed by many users out there. In the past user surveys users have asked to 'fix Neutron' first, not many have asked 'more Neutron'. Here are some actual quotes from the survey as a reminder: Would love to see Neutron stabilize (so we can get rid of Nova networking) and Heat to get moved forward. More stability / reliability in Neutron. Also, support for Cisco Insieme. Neutron is relatively unusable. It's missing quite a bit of functionality from nova-network that makes it easily usable by small to medium deployments. Get a way from migrating from nova-network multihost to neutron. Giving priority to bugs that actually affect production installations[...] I'm sure we'll collect more feedback at the coming Operators Summit, too. If you're developing Neutron, think about hopping by https://www.eventbrite.com/e/openstack-ops-mid-cycle-meetup-tickets-12149171499 b) The political happenings in Neutron [...] This is not the first time I hear about the term 'political' referred to discussions and decisions that should be technical inside OpenStack. Being Italian, I take the term 'political' in this context as an offense since it carries connotations of abuse of power, incompetence, even straight delinquency. I'd like to get to the root cause here: OpenStack has places where you can spell things out without fear of repercussions and people willing to listen. What are these 'political happenings' that you see? Write or call me, Tom, call Jonathan Bryce, Heidi Bretz or anybody else at the Foundation... We're all available to listen and maintain anonymity. I (and others at the Foundation) need to understand exactly what is causing troubles so we can fix them. Generic allegations don't help. b) One major point was other openstack/stackforge use video meetings as their primary source as well What other openstack/ (*not* stackforge) program uses video meetings? /stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Octavia] Minutes from 8/13/2014 meeting
Agenda items are numbered, and topics, as discussed, are described beneath in list format. 1) Discuss future of Octavia in light of Neutron-incubator project proposal. a) There are many problems with Neutron-Incubator as currently described b) The political happenings in Neutron leave our LBaaS patches under review unlikely to land in Juno c) The Incubator proposal doesn't affect Octavia development direction, with inclination to distance ourselves from Neutron proper d) With the Neutron Incubator proposal in current scope, efforts of people pushing forward Neutron LBaaS patches should be re-focused into Octavia. 2) Discuss operator networking requirements (carry-over from last week) a) Both HP and Rackspace seem to agree that as long as Octavia uses Neutron-like floating IPs, their networks should be able to work with proposed Octavia topologies b) (Blue Box) also wanted to meet with Rackspace's networking team during the operator summit a few weeks from now to thoroughly discuss network concerns 3) Discuss v0.5 component design proposal [https://review.openstack.org/#/c/113458/] a) Notification for back-end node health (aka being offline) isn't required for 0.5, but is a must have later b) Notification of LB health (HA Proxy, etc) is definitely a requirement in 0.5 c) Still looking for more feedback on the proposal itself 4) Discuss timeline on moving these meetings to IRC. a) Most members in favor of keeping the webex meetings for the time being b) One major point was other openstack/stackforge use video meetings as their primary source as well Sorry for the lack of density. I forgot to have the meeting recorded, but I hope I included some major points. Feel free to respond in line with any more information anyone can recall concerning the meeting information. Thanks! -Trevor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting
Hi Trevor, thanks for sharing this minutes! I would like to cooperate a bit to this project's developments, possibly without ending up being just deadweight. To this aim I have some comments inline. Salvatore On 18 August 2014 22:25, Trevor Vardeman trevor.varde...@rackspace.com wrote: Agenda items are numbered, and topics, as discussed, are described beneath in list format. 1) Discuss future of Octavia in light of Neutron-incubator project proposal. a) There are many problems with Neutron-Incubator as currently described Have you listed your concerns somewhere? AFAICT the incubator definition is in progress and feedback is very valuable at this stage. b) The political happenings in Neutron leave our LBaaS patches under review unlikely to land in Juno I am a bit disappointed if you feel like you have been victims of political discussions. The truth in my opinion is much simpler, and is that most of the neutron core team has prioritised features for achieving parity with nova-network or increasing neutron scalability and reliability. In my opinion the incubator proposal will improve this situation by making the lbaas team a lot less dependent on the neutron core team. Considering the level of attention the load balancing team has received I would not be surprised if neutron cores are topping your most-hated list! c) The Incubator proposal doesn't affect Octavia development direction, with inclination to distance ourselves from Neutron proper It depends on what do you mean by proper here. If you're into a neutron incubator, your ultimate path ideally should be integration with neutron. Instead if you're planning on total independence, then it might the case of considering the typical paths new projects follow. I'm not an expert here, but I think that usually starts from stackforge. d) With the Neutron Incubator proposal in current scope, efforts of people pushing forward Neutron LBaaS patches should be re-focused into Octavia. Which probably sounds a reasonable thing to do (and a lot less effort for you as well) 2) Discuss operator networking requirements (carry-over from last week) a) Both HP and Rackspace seem to agree that as long as Octavia uses Neutron-like floating IPs, their networks should be able to work with proposed Octavia topologies b) (Blue Box) also wanted to meet with Rackspace's networking team during the operator summit a few weeks from now to thoroughly discuss network concerns 3) Discuss v0.5 component design proposal [ https://review.openstack.org/#/c/113458/] a) Notification for back-end node health (aka being offline) isn't required for 0.5, but is a must have later b) Notification of LB health (HA Proxy, etc) is definitely a requirement in 0.5 c) Still looking for more feedback on the proposal itself I'll try and find some time to review it. 4) Discuss timeline on moving these meetings to IRC. a) Most members in favor of keeping the webex meetings for the time being b) One major point was other openstack/stackforge use video meetings as their primary source as well This is one of the reasons for which I don't attend load balancing meetings. I find IRC much simpler and effective - and is also fairer to people for whom English is not their first language. Also, perusing IRC logs is much easier than watch/listen to webex recordings. Moreover, you'd get minutes for free - and you can control the density you want them to have during the meeting! Sorry for the lack of density. I forgot to have the meeting recorded, but I hope I included some major points. Feel free to respond in line with any more information anyone can recall concerning the meeting information. Thanks! -Trevor ___ 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
Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting
Hi Salvatore, It'd be great to get your contributions in this! If you could only bring your knowledge and experience with Neutron to the table that'd be very beneficial. Looking forward to it. Comments in-line On Mon, 2014-08-18 at 23:06 +0200, Salvatore Orlando wrote: Hi Trevor, thanks for sharing this minutes! I would like to cooperate a bit to this project's developments, possibly without ending up being just deadweight. To this aim I have some comments inline. Salvatore On 18 August 2014 22:25, Trevor Vardeman trevor.varde...@rackspace.com wrote: Agenda items are numbered, and topics, as discussed, are described beneath in list format. 1) Discuss future of Octavia in light of Neutron-incubator project proposal. a) There are many problems with Neutron-Incubator as currently described Have you listed your concerns somewhere? AFAICT the incubator definition is in progress and feedback is very valuable at this stage. We have, many times. In etherpad, to Kyle and Mark in IRC meetings. Not sure how it will shape up in the end yet though. b) The political happenings in Neutron leave our LBaaS patches under review unlikely to land in Juno I am a bit disappointed if you feel like you have been victims of political discussions. The truth in my opinion is much simpler, and is that most of the neutron core team has prioritised features for achieving parity with nova-network or increasing neutron scalability and reliability. In my opinion the incubator proposal will improve this situation by making the lbaas team a lot less dependent on the neutron core team. Considering the level of attention the load balancing team has received I would not be surprised if neutron cores are topping your most-hated list! I think the main issue everyone has had was that there was an expectation that if we got our code in and went through many iterations of reviews then we'd get into Juno. We did everything asked of us and this the incubator came in very late. However, I (and I'm pretty sure most others) absolutely agree that the incubator should exist, and that the lbaas v2 belongs in there (so does v1). It was just the timing of it based on what the expectations were set forth at the summit. Neutron cores are not topping our most-hated list at all. I think we all see the cores have a ton of reviews and work to do. I think its more a symptom of two issues: 1) Neutron's scope is too large 2) If Neutron's scope wants to be that large, then adding more core reviewers seems to be the logical solution. Now the incubator can definitely solve for #1 because it has a path for spinning out. However, the fear is that the incubator will become an after thought for neutron cores. I hope this is not the case, and I have high hopes for it, but it's still a fear even from the most optimistic of people. c) The Incubator proposal doesn't affect Octavia development direction, with inclination to distance ourselves from Neutron proper It depends on what do you mean by proper here. If you're into a neutron incubator, your ultimate path ideally should be integration with neutron. Instead if you're planning on total independence, then it might the case of considering the typical paths new projects follow. I'm not an expert here, but I think that usually starts from stackforge. The incubator does have a spin out path and I believe that may be the way forward on this. I don't think spinning out should be something we should focus on too much right now until Octavia is in a good state. Either way, I'm sure we have the blessing of Kyle and Mark to spin out at some point and become a project under the Networking Program. This could be accomplished a number of ways. d) With the Neutron Incubator proposal in current scope, efforts of people pushing forward Neutron LBaaS patches should be re-focused into Octavia. Which probably sounds a reasonable thing to do (and a lot less effort for you as well) 2) Discuss operator networking requirements (carry-over from last week) a) Both HP and Rackspace seem to agree that as long as Octavia uses Neutron-like floating IPs, their networks should be able to work with proposed Octavia topologies b) (Blue Box) also wanted to meet with Rackspace's networking team during the operator summit a few weeks from now to thoroughly discuss network concerns 3) Discuss v0.5 component design proposal [https://review.openstack.org/#/c/113458/] a) Notification for back-end node health (aka being offline) isn't required for 0.5, but is a must have later b) Notification of LB health (HA Proxy, etc) is definitely
Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting
a) Most members in favor of keeping the webex meetings for the time being Correction: most of the people that like to talk over each other in a large voice conference voiced their approval of voice. Those that prefer to wait for pauses to speak were unsurprisingly silent, or tried and failed to break into the cries of love for webex. I also prefer IRC, with voice tactically as is useful. Doug On 8/18/14, 3:06 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi Trevor, thanks for sharing this minutes! I would like to cooperate a bit to this project's developments, possibly without ending up being just deadweight. To this aim I have some comments inline. Salvatore On 18 August 2014 22:25, Trevor Vardeman trevor.varde...@rackspace.com wrote: Agenda items are numbered, and topics, as discussed, are described beneath in list format. 1) Discuss future of Octavia in light of Neutron-incubator project proposal. a) There are many problems with Neutron-Incubator as currently described Have you listed your concerns somewhere? AFAICT the incubator definition is in progress and feedback is very valuable at this stage. b) The political happenings in Neutron leave our LBaaS patches under review unlikely to land in Juno I am a bit disappointed if you feel like you have been victims of political discussions. The truth in my opinion is much simpler, and is that most of the neutron core team has prioritised features for achieving parity with nova-network or increasing neutron scalability and reliability. In my opinion the incubator proposal will improve this situation by making the lbaas team a lot less dependent on the neutron core team. Considering the level of attention the load balancing team has received I would not be surprised if neutron cores are topping your most-hated list! c) The Incubator proposal doesn't affect Octavia development direction, with inclination to distance ourselves from Neutron proper It depends on what do you mean by proper here. If you're into a neutron incubator, your ultimate path ideally should be integration with neutron. Instead if you're planning on total independence, then it might the case of considering the typical paths new projects follow. I'm not an expert here, but I think that usually starts from stackforge. d) With the Neutron Incubator proposal in current scope, efforts of people pushing forward Neutron LBaaS patches should be re-focused into Octavia. Which probably sounds a reasonable thing to do (and a lot less effort for you as well) 2) Discuss operator networking requirements (carry-over from last week) a) Both HP and Rackspace seem to agree that as long as Octavia uses Neutron-like floating IPs, their networks should be able to work with proposed Octavia topologies b) (Blue Box) also wanted to meet with Rackspace's networking team during the operator summit a few weeks from now to thoroughly discuss network concerns 3) Discuss v0.5 component design proposal [https://review.openstack.org/#/c/113458/] a) Notification for back-end node health (aka being offline) isn't required for 0.5, but is a must have later b) Notification of LB health (HA Proxy, etc) is definitely a requirement in 0.5 c) Still looking for more feedback on the proposal itself I'll try and find some time to review it. 4) Discuss timeline on moving these meetings to IRC. a) Most members in favor of keeping the webex meetings for the time being b) One major point was other openstack/stackforge use video meetings as their primary source as well This is one of the reasons for which I don't attend load balancing meetings. I find IRC much simpler and effective - and is also fairer to people for whom English is not their first language. Also, perusing IRC logs is much easier than watch/listen to webex recordings. Moreover, you'd get minutes for free - and you can control the density you want them to have during the meeting! Sorry for the lack of density. I forgot to have the meeting recorded, but I hope I included some major points. Feel free to respond in line with any more information anyone can recall concerning the meeting information. Thanks! -Trevor ___ 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
Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting
I agree almost completely with Brandon¹s comments on the incubator. For Octavia, I think we need to not stress neutron vs incubator vs spin-out, and just focus on writing some load-balancing code. We¹ve spent far too much time in Juno working on processes, glue, and APIs, and precious little on moving packets around or adding LB features. And if we re-focus now on processes, glue, and APIs, I think we¹ll be missing the mark. I certainly don¹t hate the neutron cores; quite the opposite. But what I absolutely *NEED* is a fairly predictable process for where/how code will land, and what sorts of resources it will take to get there. It is very difficult right now to plan/evangelize company resources, when the rules are almost constantly in flux. Or appear to be so, from an outside perspective. Review cycles are a huge issue. Of course, adding a bunch of reviewers is not a recipe for an increase in stability. I¹m not going to focus overly much on the incubator process needing to be perfect. It lives or dies with people, their judgement, and their good faith effort to see all of this stuff succeed. If others are not bringing good faith to the table, then it¹s not something that any process is going to fix. Thanks, doug On 8/18/14, 3:44 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Hi Salvatore, It'd be great to get your contributions in this! If you could only bring your knowledge and experience with Neutron to the table that'd be very beneficial. Looking forward to it. Comments in-line On Mon, 2014-08-18 at 23:06 +0200, Salvatore Orlando wrote: Hi Trevor, thanks for sharing this minutes! I would like to cooperate a bit to this project's developments, possibly without ending up being just deadweight. To this aim I have some comments inline. Salvatore On 18 August 2014 22:25, Trevor Vardeman trevor.varde...@rackspace.com wrote: Agenda items are numbered, and topics, as discussed, are described beneath in list format. 1) Discuss future of Octavia in light of Neutron-incubator project proposal. a) There are many problems with Neutron-Incubator as currently described Have you listed your concerns somewhere? AFAICT the incubator definition is in progress and feedback is very valuable at this stage. We have, many times. In etherpad, to Kyle and Mark in IRC meetings. Not sure how it will shape up in the end yet though. b) The political happenings in Neutron leave our LBaaS patches under review unlikely to land in Juno I am a bit disappointed if you feel like you have been victims of political discussions. The truth in my opinion is much simpler, and is that most of the neutron core team has prioritised features for achieving parity with nova-network or increasing neutron scalability and reliability. In my opinion the incubator proposal will improve this situation by making the lbaas team a lot less dependent on the neutron core team. Considering the level of attention the load balancing team has received I would not be surprised if neutron cores are topping your most-hated list! I think the main issue everyone has had was that there was an expectation that if we got our code in and went through many iterations of reviews then we'd get into Juno. We did everything asked of us and this the incubator came in very late. However, I (and I'm pretty sure most others) absolutely agree that the incubator should exist, and that the lbaas v2 belongs in there (so does v1). It was just the timing of it based on what the expectations were set forth at the summit. Neutron cores are not topping our most-hated list at all. I think we all see the cores have a ton of reviews and work to do. I think its more a symptom of two issues: 1) Neutron's scope is too large 2) If Neutron's scope wants to be that large, then adding more core reviewers seems to be the logical solution. Now the incubator can definitely solve for #1 because it has a path for spinning out. However, the fear is that the incubator will become an after thought for neutron cores. I hope this is not the case, and I have high hopes for it, but it's still a fear even from the most optimistic of people. c) The Incubator proposal doesn't affect Octavia development direction, with inclination to distance ourselves from Neutron proper It depends on what do you mean by proper here. If you're into a neutron incubator, your ultimate path ideally should be integration with neutron. Instead if you're planning on total independence, then it might the case of considering the typical paths new projects follow. I'm not an expert here, but I think that usually starts from stackforge. The incubator does have a spin out path and I believe that may be the way forward on this. I don't think spinning out should be something we should focus on too much right now
Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting
I agree pretty strongly with Brandon's and Doug's comments as well. And I did want to clarify that I certainly don't hate the Neutron cores either. I feel like we (those working on Neutron LBaaS and the Cores) made commitments to each other both at the Atlanta summit and the mid-cycle hackathon, including taking on additional work we otherwise wouldn't have done in order to work with the Neutron team in good faith. I feel like we upheld our end of the deal, but without getting the reviews we need to get into Juno, and with LBaaS becoming the poster child (or proof of concept, or guinea pig, depending on your level of cynicism) for projects that should go into Neutron Incubator... well, here we are about to hit Juno-3 and there's essentially zero chance we're going to get in. All that is to say, I think the cores we've been working with embarked on this in good faith, but unexpected happenings in the Neutron community have necessitated the events as they are happening. I think I understand *why* things have happened as they have, but I can't help but feel like our team was betrayed here. And it's certainly not going to be any easier to convince our bosses that our time working on Neutron LBaaS over the last few months was well spent when the features and changes we need are no closer to becoming part of the official, accepted code base. (Heck, if Brandon is the voice of Optimism in our defacto team, then you can call me the voice of Skepticism in it: It's also conceivable that with the extra complication of neutron-incubator graduation being worked through, it is likely that we will not see our changes get into Kilo either!) I do hope that they take our previously voiced concerns about neutron-incubator very seriously (particularly the ones about moving Neutron LBaaS v1 into incubator, and taking meaningful, tangible steps to solve the core reviewer bandwidth problem that I think is the *real* reason it takes so long to get major changes into Neutron.) At this time, though, I feel like prudence demands we spend time making Octavia happen-- after all, we can only go through so many cycles where we effectively have nothing to show for our work before we'll all be out of our jobs. :/ On joining the weekly meetings and otherwise contributing: We'd love to have you attend Salvatore! If you (or anyone else interested) are free at 20:00 UTC on Wednesdays, shoot me a note and I can get you the webex connection details. If you're not able to make it to these-- well, in any case we mean for in-depth discussions to happen either via the mailing list or IRC (we're in #openstack-lbaas ). Right now the meetings are mostly being used to answer questions, raise concerns and drive consensus without usually going into novel discussions that weren't already started via the mailing list or IRC. On holding these meetings via IRC: Actually, we did discuss each of the points you brought up Salvatore. And yes Doug, a voice meeting with variable and sometimes high latency is going to naturally prefer those with more boorish communication styles (like me) who (allegedly accidentally) end up walking over the voice of people who are either quieter or prefer to wait for pauses to communicate. (Sorry about that.) The plus-side of voice and video communication is much higher bandwidth (even for people like me who type quite quickly), and many kinds of human communication are much more effective when voice and video are used versus simple text. ( http://www.psychologytoday.com/blog/beyond-words/201109/is-nonverbal-communication-numbers-game ) We did put it up for an informal vote and the consensus was to keep doing the video meetings for the time being (especially while we're still bootstrapping this project). But I did point out that asking the people who joined the video meeting whether they wanted to keep doing video meetings might simply be a form of confirmation bias. ;) Thanks, Stephen On Mon, Aug 18, 2014 at 3:46 PM, Doug Wiegley do...@a10networks.com wrote: I agree almost completely with Brandon¹s comments on the incubator. For Octavia, I think we need to not stress neutron vs incubator vs spin-out, and just focus on writing some load-balancing code. We¹ve spent far too much time in Juno working on processes, glue, and APIs, and precious little on moving packets around or adding LB features. And if we re-focus now on processes, glue, and APIs, I think we¹ll be missing the mark. I certainly don¹t hate the neutron cores; quite the opposite. But what I absolutely *NEED* is a fairly predictable process for where/how code will land, and what sorts of resources it will take to get there. It is very difficult right now to plan/evangelize company resources, when the rules are almost constantly in flux. Or appear to be so, from an outside perspective. Review cycles are a huge issue. Of course, adding a bunch of reviewers is not a recipe for an increase in stability. I¹m not going to focus overly
Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting
So now that is two people on this thread that are treating moving lbaas v1 to incubator as an “of course, duh” kind of thing. I do not agree. Insofar as most of neutron advanced services is feeling the velocity and maturity pain, sure. But lbaas v2 has NO dependency on v1, it’s “stable”, been shipping for several cycles, has users… it would be odd to just up and disappear in Juno. Seems to make more sense to let it continue in maintenance, likely deprecated in Kilo, and be removed as part of a normal lifecycle. v2 is nowhere near as far along, partly because we jumped through some extra hoops, but whatever, they are not in identical situations. Thanks, Doug On 8/18/14, 7:49 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: I agree pretty strongly with Brandon's and Doug's comments as well. And I did want to clarify that I certainly don't hate the Neutron cores either. I feel like we (those working on Neutron LBaaS and the Cores) made commitments to each other both at the Atlanta summit and the mid-cycle hackathon, including taking on additional work we otherwise wouldn't have done in order to work with the Neutron team in good faith. I feel like we upheld our end of the deal, but without getting the reviews we need to get into Juno, and with LBaaS becoming the poster child (or proof of concept, or guinea pig, depending on your level of cynicism) for projects that should go into Neutron Incubator... well, here we are about to hit Juno-3 and there's essentially zero chance we're going to get in. All that is to say, I think the cores we've been working with embarked on this in good faith, but unexpected happenings in the Neutron community have necessitated the events as they are happening. I think I understand *why* things have happened as they have, but I can't help but feel like our team was betrayed here. And it's certainly not going to be any easier to convince our bosses that our time working on Neutron LBaaS over the last few months was well spent when the features and changes we need are no closer to becoming part of the official, accepted code base. (Heck, if Brandon is the voice of Optimism in our defacto team, then you can call me the voice of Skepticism in it: It's also conceivable that with the extra complication of neutron-incubator graduation being worked through, it is likely that we will not see our changes get into Kilo either!) I do hope that they take our previously voiced concerns about neutron-incubator very seriously (particularly the ones about moving Neutron LBaaS v1 into incubator, and taking meaningful, tangible steps to solve the core reviewer bandwidth problem that I think is the *real* reason it takes so long to get major changes into Neutron.) At this time, though, I feel like prudence demands we spend time making Octavia happen-- after all, we can only go through so many cycles where we effectively have nothing to show for our work before we'll all be out of our jobs. :/ On joining the weekly meetings and otherwise contributing: We'd love to have you attend Salvatore! If you (or anyone else interested) are free at 20:00 UTC on Wednesdays, shoot me a note and I can get you the webex connection details. If you're not able to make it to these-- well, in any case we mean for in-depth discussions to happen either via the mailing list or IRC (we're in #openstack-lbaas ). Right now the meetings are mostly being used to answer questions, raise concerns and drive consensus without usually going into novel discussions that weren't already started via the mailing list or IRC. On holding these meetings via IRC: Actually, we did discuss each of the points you brought up Salvatore. And yes Doug, a voice meeting with variable and sometimes high latency is going to naturally prefer those with more boorish communication styles (like me) who (allegedly accidentally) end up walking over the voice of people who are either quieter or prefer to wait for pauses to communicate. (Sorry about that.) The plus-side of voice and video communication is much higher bandwidth (even for people like me who type quite quickly), and many kinds of human communication are much more effective when voice and video are used versus simple text. ( http://www.psychologytoday.com/blog/beyond-words/201109/is-nonverbal-commu nication-numbers-game ) We did put it up for an informal vote and the consensus was to keep doing the video meetings for the time being (especially while we're still bootstrapping this project). But I did point out that asking the people who joined the video meeting whether they wanted to keep doing video meetings might simply be a form of confirmation bias. ;) Thanks, Stephen On Mon, Aug 18, 2014 at 3:46 PM, Doug Wiegley do...@a10networks.com wrote: I agree almost completely with Brandon¹s comments on the incubator. For Octavia, I think we need to not stress neutron vs incubator vs spin-out, and just focus on writing some load-balancing code. We¹ve
