Open Stack

Howdy,

Here is my first pass at allowing different voters for different pipelines.
https://review.openstack.org/#/c/97391/2

Cheers,
Josh

Rackspace Australia

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140603/131e6983/attachment.html>