<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 20, 2013 at 1:58 PM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><p dir="ltr"><br>
On Sep 20, 2013 1:27 PM, "Dan Wendlandt" <<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>> wrote:<br>
><br>
><br>
><br>
><br>
> On Fri, Sep 20, 2013 at 1:09 PM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>> wrote:<br>
>><br>
>> On Fri, Sep 20, 2013 at 11:52 AM, Russell Bryant <<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>> wrote:<br>
>>><br>
>>> On 09/20/2013 02:02 PM, Dan Wendlandt wrote:<br>
>>> > I think the real problem here is that in Nova there are bug fixes that<br>
>>> > are tiny and very important to a particular subset of the user<br>
>>> > population and yet have been around for well over a month without<br>
>>> > getting a single core review.<br>
>>> ><br>
>>> > Take for example <a href="https://review.openstack.org/#/c/40298/" target="_blank">https://review.openstack.org/#/c/40298/</a> , which fixes<br>
>>> > an important snapshot bug for the vmwareapi driver.  This was posted<br>
>>> > well over a month ago on August 5th.  It is a solid patch, is 54<br>
>>> > new/changed lines including unit test enhancements.  The commit message<br>
>>> > clearly shows which tempest tests it fixes.  It has been reviewed by<br>
>>> > many vmware reviewers with +1s for a long time, but the patch just keeps<br>
>>> > having to be rebased as it sits waiting for core reviewer attention.<br>
>><br>
>><br>
>> 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.<br>



>><br>
>> I while back Russell announced we would like all virt drivers have a public functional testing system by the release of Icehouse (<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-July/011280.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-July/011280.html</a>). 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 (<a href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix" target="_blank">https://wiki.openstack.org/wiki/HypervisorSupportMatrix</a> -- "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.<br>



><br>
><br>
><br>
> Hi Joe,<br>
><br>
> 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.<br>



><br>
> Dan<br></p>
</div><p dir="ltr">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. <br>

</p></blockquote><div><br></div><div style>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.</div>

<div style><br></div><div style>Dan</div><div style><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"></p><div><div class="h5">



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

~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div>
</div></div>