Open Stack

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

>
> 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.
>

Great.  By the way, all of this automated tempest testing is running nested
on top of a physical OpenStack on vSphere cloud we run internally.  That
cloud has the ability to host "labs" that are externally accessible.  So if
you're a core Nova reviewer (or other person who does a lot of Nova
reviews), I could definitely look into how we can get you access to a
devstack + vSphere environment for your personal use of reviewing + testing
patches.  Anything I can do to make a core reviewers life easier here, I'm
all for.  Feel free to reach out to me off-list.

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
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > _______________________________________________
> > 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/337ff5fd/attachment.html>