Open Stack

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:dougw at 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" <sbalukoff at 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-co
>mmu
>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 <dougw at 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 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.logan at 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.vardeman at 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
>>>         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!
>>
>>These meetings are just for Octavia right now and will eventually get 
>>into IRC.  The weekly LBaaS meeting is still in IRC every thursday at
>>14:00 UTC.  I've just been pushing for IRC because I hate phone/video 
>>conferences with many people.  The reasons you outlined are definitely 
>>the main reasons to do it, I'm just being selfish with my own reason.
>>The plan is to eventually get it on IRC.  With the more interest we 
>>get on this the more we need to speed this up.
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>             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 at lists.openstack.org
>>>
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> 
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
><http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>Thanks,
>>Brandon
>>
>>_______________________________________________
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>
>
>
>
>--
>Stephen Balukoff
>Blue Box Group, LLC
>(800)613-4305 x807

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev