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