On Wed, May 28, 2014 at 10:54 PM, Joshua Hesketh < [email protected]> wrote:
> On 5/29/14 8:52 AM, James E. Blair wrote: > >> Devananda van der Veen <[email protected]> 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 > > Fantastic! Please don't hesitate to poke me (or anyone in #openstack-ironic) with questions, if you have any. -Devananda
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
