<div dir="ltr">I agree pretty strongly with Brandon's and Doug's comments as well.<div><br></div><div>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.</div>
<div><br></div><div>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!)</div>
<div><br></div><div>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. :/</div>
<div><br></div><div>On joining the weekly meetings and otherwise contributing:</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>On holding these meetings via IRC:</div><div><br></div><div>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. ( <a href="http://www.psychologytoday.com/blog/beyond-words/201109/is-nonverbal-communication-numbers-game">http://www.psychologytoday.com/blog/beyond-words/201109/is-nonverbal-communication-numbers-game</a> )</div>
<div><br></div><div>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. ;)</div>
<div><br></div><div>Thanks,</div><div>Stephen</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 18, 2014 at 3:46 PM, Doug Wiegley <span dir="ltr"><<a href="mailto:dougw@a10networks.com" target="_blank">dougw@a10networks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree almost completely with Brandon¹s comments on the incubator.<br>
<br>
For Octavia, I think we need to not stress neutron vs incubator vs<br>
spin-out, and just focus on writing some load-balancing code. We¹ve spent<br>
far too much time in Juno working on processes, glue, and APIs, and<br>
precious little on moving packets around or adding LB features. And if we<br>
re-focus now on processes, glue, and APIs, I think we¹ll be missing the<br>
mark.<br>
<br>
I certainly don¹t hate the neutron cores; quite the opposite. But what I<br>
absolutely *NEED* is a fairly predictable process for where/how code will<br>
land, and what sorts of resources it will take to get there. It is very<br>
difficult right now to plan/evangelize company resources, when the rules<br>
are almost constantly in flux. Or appear to be so, from an outside<br>
perspective.<br>
<br>
Review cycles are a huge issue. Of course, adding a bunch of reviewers is<br>
not a recipe for an increase in stability.<br>
<br>
I¹m not going to focus overly much on the incubator process needing to be<br>
perfect. It lives or dies with people, their judgement, and their good<br>
faith effort to see all of this stuff succeed. If others are not bringing<br>
good faith to the table, then it¹s not something that any process is going<br>
to fix.<br>
<br>
Thanks,<br>
doug<br>
<div class="HOEnZb"><div class="h5"><br>
On 8/18/14, 3:44 PM, "Brandon Logan" <<a href="mailto:brandon.logan@RACKSPACE.COM">brandon.logan@RACKSPACE.COM</a>> wrote:<br>
<br>
>Hi Salvatore,<br>
>It'd be great to get your contributions in this! If you could only bring<br>
>your knowledge and experience with Neutron to the table that'd be very<br>
>beneficial. Looking forward to it.<br>
><br>
>Comments in-line<br>
><br>
>On Mon, 2014-08-18 at 23:06 +0200, Salvatore Orlando wrote:<br>
>> Hi Trevor,<br>
>><br>
>><br>
>> thanks for sharing this minutes!<br>
>> I would like to cooperate a bit to this project's developments,<br>
>> possibly without ending up being just deadweight.<br>
>><br>
>><br>
>> To this aim I have some comments inline.<br>
>><br>
>><br>
>> Salvatore<br>
>><br>
>><br>
>> On 18 August 2014 22:25, Trevor Vardeman<br>
>> <<a href="mailto:trevor.vardeman@rackspace.com">trevor.vardeman@rackspace.com</a>> wrote:<br>
>> Agenda items are numbered, and topics, as discussed, are<br>
>> described beneath in list format.<br>
>><br>
>><br>
>> 1) Discuss future of Octavia in light of Neutron-incubator<br>
>> project proposal.<br>
>> a) There are many problems with Neutron-Incubator as<br>
>> currently described<br>
>><br>
>><br>
>> Have you listed your concerns somewhere? AFAICT the incubator<br>
>> definition is in progress and feedback is very valuable at this stage.<br>
><br>
>We have, many times. In etherpad, to Kyle and Mark in IRC meetings.<br>
>Not sure how it will shape up in the end yet though.<br>
><br>
>><br>
>><br>
>> b) The political happenings in Neutron leave our LBaaS<br>
>> patches under review unlikely to land in Juno<br>
>><br>
>><br>
>> I am a bit disappointed if you feel like you have been victims of<br>
>> political discussions.<br>
>> The truth in my opinion is much simpler, and is that most of the<br>
>> neutron core team has prioritised features for achieving parity with<br>
>> nova-network or increasing neutron scalability and reliability.<br>
>> In my opinion the incubator proposal will improve this situation by<br>
>> making the lbaas team a lot less dependent on the neutron core team.<br>
>> Considering the level of attention the load balancing team has<br>
>> received I would not be surprised if neutron cores are topping your<br>
>> most-hated list!<br>
><br>
>I think the main issue everyone has had was that there was an<br>
>expectation that if we got our code in and went through many iterations<br>
>of reviews then we'd get into Juno. We did everything asked of us and<br>
>this the incubator came in very late. However, I (and I'm pretty sure<br>
>most others) absolutely agree that the incubator should exist, and that<br>
>the lbaas v2 belongs in there (so does v1). It was just the timing of<br>
>it based on what the expectations were set forth at the summit.<br>
><br>
>Neutron cores are not topping our most-hated list at all. I think we<br>
>all see the cores have a ton of reviews and work to do. I think its<br>
>more a symptom of two issues: 1) Neutron's scope is too large 2) If<br>
>Neutron's scope wants to be that large, then adding more core reviewers<br>
>seems to be the logical solution.<br>
><br>
>Now the incubator can definitely solve for #1 because it has a path for<br>
>spinning out. However, the fear is that the incubator will become an<br>
>after thought for neutron cores. I hope this is not the case, and I<br>
>have high hopes for it, but it's still a fear even from the most<br>
>optimistic of people.<br>
><br>
>><br>
>> c) The Incubator proposal doesn't affect Octavia<br>
>> development direction, with inclination to distance ourselves<br>
>> from Neutron proper<br>
>><br>
>><br>
>> It depends on what do you mean by "proper" here. If you're into a<br>
>> neutron incubator, your ultimate path ideally should be integration<br>
>> with neutron.<br>
>> Instead if you're planning on total independence, then it might the<br>
>> case of considering the typical paths new projects follow. I'm not an<br>
>> expert here, but I think that usually starts from stackforge.<br>
><br>
>The incubator does have a spin out path and I believe that may be the<br>
>way forward on this. I don't think spinning out should be something we<br>
>should focus on too much right now until Octavia is in a good state.<br>
>Either way, I'm sure we have the blessing of Kyle and Mark to spin out<br>
>at some point and become a project under the Networking Program. This<br>
>could be accomplished a number of ways.<br>
><br>
>><br>
>> d) With the Neutron Incubator proposal in current scope,<br>
>> efforts of people pushing forward Neutron LBaaS patches should<br>
>> be re-focused into Octavia.<br>
>><br>
>><br>
>> Which probably sounds a reasonable thing to do (and a lot less effort<br>
>> for you as well)<br>
>><br>
>><br>
>> 2) Discuss operator networking requirements (carry-over from<br>
>> last week)<br>
>> a) Both HP and Rackspace seem to agree that as long as<br>
>> Octavia uses Neutron-like floating IPs, their networks should<br>
>> be able to work with proposed Octavia topologies<br>
>> b) (Blue Box) also wanted to meet with Rackspace's<br>
>> networking team during the operator summit a few weeks from<br>
>> now to thoroughly discuss network concerns<br>
>><br>
>><br>
>> 3) Discuss v0.5 component design proposal<br>
>> [<a href="https://review.openstack.org/#/c/113458/" target="_blank">https://review.openstack.org/#/c/113458/</a>]<br>
>> a) Notification for back-end node health (aka being<br>
>> offline) isn't required for 0.5, but is a must have later<br>
>> b) Notification of LB health (HA Proxy, etc) is definitely<br>
>> a requirement in 0.5<br>
>> c) Still looking for more feedback on the proposal itself<br>
>><br>
>><br>
>> I'll try and find some time to review it.<br>
>><br>
>><br>
>> 4) Discuss timeline on moving these meetings to IRC.<br>
>> a) Most members in favor of keeping the webex meetings for<br>
>> the time being<br>
>> b) One major point was other openstack/stackforge use<br>
>> video meetings as their "primary" source as well<br>
>><br>
>><br>
>> This is one of the reasons for which I don't attend load balancing<br>
>> meetings.<br>
>> I find IRC much simpler and effective - and is also fairer to people<br>
>> for whom English is not their first language.<br>
>> Also, perusing IRC logs is much easier than watch/listen to webex<br>
>> recordings.<br>
>> Moreover, you'd get minutes for free - and you can control the density<br>
>> you want them to have during the meeting!<br>
><br>
>These meetings are just for Octavia right now and will eventually get<br>
>into IRC. The weekly LBaaS meeting is still in IRC every thursday at<br>
>14:00 UTC. I've just been pushing for IRC because I hate phone/video<br>
>conferences with many people. The reasons you outlined are definitely<br>
>the main reasons to do it, I'm just being selfish with my own reason.<br>
>The plan is to eventually get it on IRC. With the more interest we get<br>
>on this the more we need to speed this up.<br>
><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Sorry for the lack of density. I forgot to have the<br>
>> meeting recorded, but I hope I included some major points.<br>
>> Feel free to respond in line with any more information anyone<br>
>> can recall concerning the meeting information. Thanks!<br>
>><br>
>><br>
>> -Trevor<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>><br>
>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
>Thanks,<br>
>Brandon<br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div>