<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Howdy,<br>
<br>
Here is my first pass at allowing different voters for different
pipelines.<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/97391/2">https://review.openstack.org/#/c/97391/2</a><br>
<br>
Cheers,<br>
Josh<br>
<pre class="moz-signature" cols="72">Rackspace Australia</pre>
On 5/30/14 3:30 AM, Devananda van der Veen wrote:<br>
</div>
<blockquote
cite="mid:CAExZKEpFC68f0JmsEXjRJYqmoR+vkK69hVnPzJRaXqHrZ17ffw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<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
moz-do-not-send="true"
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 moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>