Open Stack

On Fri, Sep 20, 2013 at 1:09 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

> On Fri, Sep 20, 2013 at 11:52 AM, Russell Bryant <rbryant at redhat.com>wrote:
>
>> On 09/20/2013 02:02 PM, Dan Wendlandt wrote:
>> > I think the real problem here is that in Nova there are bug fixes that
>> > are tiny and very important to a particular subset of the user
>> > population and yet have been around for well over a month without
>> > getting a single core review.
>> >
>> > Take for example https://review.openstack.org/#/c/40298/ , which fixes
>> > an important snapshot bug for the vmwareapi driver.  This was posted
>> > well over a month ago on August 5th.  It is a solid patch, is 54
>> > new/changed lines including unit test enhancements.  The commit message
>> > clearly shows which tempest tests it fixes.  It has been reviewed by
>> > many vmware reviewers with +1s for a long time, but the patch just keeps
>> > having to be rebased as it sits waiting for core reviewer attention.
>>
>
> Personally I tend not to review many vmwareapi patches because without
> seeing any public functional tests or being able to run the patch myself, I
> am uncomfortable saying it 'looks good to me'. All I can do is make sure
> the code looks pythonic and make no assessment on if the patch works or
> not. With no shortage of patches to review I tend to review other patches
> instead.
>
> I while back Russell announced we would like all virt drivers have a
> public functional testing system by the release of Icehouse (
> http://lists.openstack.org/pipermail/openstack-dev/2013-July/011280.html).
> Public functional testing would allow me to review vmwareapi patches with
> almost the same level of confidence as with a driver that we gate on and
> that I can trivially try out, such as libvirt.  Until then, if we put an
> explicit comment in the release notes explicitly saying that vmwareapi is a
> group C virt driver (
> https://wiki.openstack.org/wiki/HypervisorSupportMatrix -- "These drivers
> have minimal testing and may or may not work at any given time. Use them at
> your own risk") that would address my concerns and I would be happy to +2
> vmwareapi patches based just on if the code looks correct and not on how
> well the patch works.
>


Hi Joe,

I couldn't agree more.  In fact, the VMware team has been working hard to
get a fully-automated CI infrastructure setup and integrated with upstream
Gerrit.  We already run the tempest tests internally and have been manually
posting tempest results for some patches.  I wouldn't want to speak for the
dev owner, but I think within a very short time (before Havana) you will
begin seeing automated reports for tempest tests on top of vSphere showing
up on Gerrit.  I agree that this will really help core reviewers gain
confidence that not only does the code "look OK", but that it works well
too.

Dan







>
>
> >
>> > To me, the high-level take away is that it is hard to get new
>> > contributors excited about working on Nova when their well-written and
>> > well-targeted bug fixes just sit there, getting no feedback and not
>> > moving closer to merging.  The bug above was the developer's first patch
>> > to OpenStack and while he hasn't complained a bit, I think the
>> > experience is far from the community behavior that we need to encourages
>> > new, high-quality contributors from diverse sources.  For Nova to
>> > succeed in its goals of being a platform agnostic cloud layer, I think
>> > this is something we need a community strategy to address and I'd love
>> > to see it as part of the discussion put forward by those people
>> > nominating themselves as PTL.
>>
>> I've discussed this topic quite a bit in the past.  In short, my
>> approach has been:
>>
>> 1) develop metrics
>> 2) set goals
>> 3) track progress against those goals
>>
>> The numbers I've been using are here:
>>
>>     http://russellbryant.net/openstack-stats/nova-openreviews.html
>>
>> Right now we're running a bit behind the set goal of keeping the average
>> under 5 days for the latest revision (1st set of numbers), and 7 days
>> for the oldest revision since the last -1 (3rd set of numbers).
>> However, Nova is now (and has been since I've been tracking this) below
>> the average for all OpenStack projects:
>>
>>     http://russellbryant.net/openstack-stats/all-openreviews.html
>>
>> Review prioritization is not something that I or anyone else can
>> strictly control, but we can provide tools and guidelines to help.  You
>> can find some notes on that here:
>>
>>     https://wiki.openstack.org/wiki/Nova/CoreTeam#Review_Prioritization
>>
>> There is also an aspect of karma involved in all of this that I think
>> phttp://summit.openstack.org/cfp/details/4lays a big part when it comes
>> to the vmware driver patches.  To get review attention, someone has to
>> *want* to review it.  To get people to want to review your stuff, it can
>> either be technology they are interested in, or they just want to help
>> you out personally.
>>
>> There aren't many Nova developers that use the vmware driver, so you've
>> got to work on building karma with the team.  That means contributing to
>> other areas, which honestly, I haven't seen much of from this group.  I
>> think that would go a long way.
>>
>> I think if you review the history of vmware patches, you'll see my name
>> as a reviewer on many (or perhaps most) of them, so I hope nobody thinks
>> that I personally am trying stall things here.  This is just based on my
>> experience across all contributions.
>>
>> I already put a session on the design summit schedule to discuss the
>> future of drivers.  I'm open to alternative approaches for driver
>> maintenance, including moving some of them (such as the vmware driver)
>> into another tree where the developers focused on it can merge their
>> code without waiting for nova-core review.
>>
>> http://summit.openstack.org/cfp/details/4
>>
>> --
>> Russell Bryant
>>
>> _______________________________________________
>> 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
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130920/521dd9df/attachment.html>