<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 28, 2014 at 10:54 PM, Joshua Hesketh <span dir="ltr"><<a href="mailto:joshua.hesketh@rackspace.com" target="_blank">joshua.hesketh@rackspace.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="HOEnZb"><div class="h5">On 5/29/14 8:52 AM, James E. Blair wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Devananda van der Veen <<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@gmail.com</a>> writes:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all!<br>
<br>
This is a follow-up to several summit discussions on<br>
how-do-we-deprecate-baremetal, a summary of the plan forward, a call to<br>
raise awareness of the project's status, and hopefully gain some interest<br>
from folks on nova-core to help with spec and code reviews.<br>
<br>
The nova.virt.ironic driver lives in Ironic's git tree today [1]. We're<br>
cleaning it up and submitting it to Nova again this cycle. I've posted<br>
specs [2] outlining the design and planned upgrade process. Earlier today,<br>
we enabled voting in Ironic's check and gate queues for the<br>
tempest-dsvm-virtual-ironic job. This runs a tempest scenario test [3]<br>
against devstack, exercising Nova with the Ironic driver to PXE boot a<br>
virtual machine. It has been running for a few months on Ironic, and has<br>
been stable for more than a month. However, because Ironic is not<br>
integrated, we also can't vote in check/gate queues on integrated projects<br>
(like Nova). We can - and do - report the test result in a non-voting way,<br>
though that's easy to miss, since it looks like every other non-voting test.<br>
<br>
At the summit [4], it was suggested that we make this job report as though<br>
it were a third-party CI test for a Nova driver. This would be removed at<br>
the time that Ironic graduates and the job is allowed to vote in the gate.<br>
Until that time, I'm happy to have the nova.virt.ironic driver reporting as<br>
a third-party driver (even though it's not) simply to help raise awareness<br>
(third-party CI jobs are watched more closely than non-voting jobs) and<br>
decrease the likelihood that Nova developers will inadvertently break<br>
Ironic's gate.<br>
<br>
Given that there's a concrete plan forward, why am I sending this email to<br>
all three teams? A few reasons:<br>
- document the plan that we discussed<br>
- many people from infra and nova were not present during the discussion<br>
and may not be aware of the details<br>
- I may have gotten something wrong (it was a long week)<br>
- and mostly because I don't technically know how to make an upstream job<br>
report as though it's a third-party job, and am hoping someone wants to<br>
volunteer to help figure that out<br>
</blockquote>
I think it's a reasonable plan.  To elaborate a bit, I think we<br>
identified three categories of jobs that we run:<br>
<br>
a) jobs that are voting<br>
b) jobs that are non-voting because they are advisory<br>
c) jobs that are non-voting for policy reasons but we feel fairly<br>
    strongly about<br>
<br>
There's a pretty subtle distinction between b and c.  Ideally, there<br>
shouldn't be any.  We've tried to minimize the number of non-voting jobs<br>
to make sure that people don't ignore them.  Nonetheless, it seems that<br>
a large enough number of people still do that non-voting jobs are<br>
considered ineffective in Nova.  I think it's worth noting the potential<br>
danger of de-emphasizing the actual results.  It may make other<br>
non-voting jobs even less effective than they already are.<br>
<br>
The intent is to make the jobs described by (c) into voting jobs, but in<br>
a way that they can still be overridden if need be.  The aim is to help<br>
new (eg, incubated) projects join the integrated gate in a way that lets<br>
them prove they are sufficiently mature to do so without impacting the<br>
currently integrated projects.  I believe we're currently thinking that<br>
point is after their integration approval.  If we are comfortable with<br>
incubated projects being able to block the integrated gate earlier, we<br>
could simply make the non-voting jobs voting instead.<br>
<br>
Back to the proposal at hand.  I think we should call the kinds of jobs<br>
described in (c) as "non-binding".<br>
<br>
The best way to do that is to register a second user with Gerrit for<br>
Zuul to use, and have it report non-binding jobs with a +/- 1 vote in<br>
the check queue that is separate from the normal "Jenkins" vote.  In<br>
order to do that, we will have to modify Zuul to be able to support a<br>
second user, and associate that user with a pipeline.  Then configure a<br>
new "non-binding" pipeline to use that user and run the desired jobs.<br>
<br>
Note that a similar problem of curation may occur with the non-binding<br>
jobs.  If we run jobs for the incubated projects Foo and Bar, they will<br>
share a vote in Gerrit, and Nova developers will have to examine the<br>
results of -1 votes; if Bar consistently fails tests, it may need to be<br>
made non-voting or removed to avoid obscuring Foo's results.<br>
<br>
I expect the Zuul modification to take an experienced Zuul developer<br>
about 2-3 days to write, or an inexperienced one about a week.  If no<br>
one else has started it by then, I will probably have some time around<br>
the middle of the cycle to hack on it.  In the mean time, we may want to<br>
make sure that the number of non-voting jobs is at a minimum (and<br>
further reduce them if possible), and emphasize to reviewers the<br>
importance of checking posted results.<br>
</blockquote>
<br></div></div>
I like this plan. I can make a start on implementing this :-)<br>
<br>
Cheers,<br>
Josh<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Fantastic! Please don't hesitate to poke me (or anyone in #openstack-ironic) with questions, if you have any.</div><div><br></div>

<div>-Devananda </div></div></div></div>