Open Stack

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
>
>Thanks,
>Brandon
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev