Open Stack

On Sep 20, 2013 1:27 PM, "Dan Wendlandt" <dan at nicira.com> wrote:
>
>
>
>
> 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

Awesome, when that happens I hope to review more vmwareapi patches.  Part
of the trick will be in how I can see that after a nova patch is merged the
vmwareapi system will cover that case going forward.
>
>
>
>
>
>
>>
>>
>>
>>> >
>>> > 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130920/1817ba43/attachment.html>