[openstack-dev] [nova][infra][ci] bulk repeating a test job on a single review in parallel ?

Kashyap Chamarthy kchamart at redhat.com
Mon Jul 4 06:22:11 UTC 2016


On Fri, Jul 01, 2016 at 02:35:34PM +0000, Jeremy Stanley wrote:
> On 2016-07-01 15:39:10 +0200 (+0200), Kashyap Chamarthy wrote:
> > [Snip description of some nice debugging.]
> > 
> > > I'd really love it if there was
> > > 
> > >  1. the ability to request checking of just specific jobs eg
> > > 
> > >       "recheck gate-tempest-dsvm-multinode-full"
> > 
> > Yes, this would really be desirable.  I recall once asking this exact
> > question on #openstack-infra, but can't find Infra team's response to
> > that.
> 
> The challenge here is that you want to make sure it can't be used to
> recheck individual jobs until you have them all passing (like
> picking a pin and tumbler lock). The temptation to recheck-spam
> nondeterministically failing changes is already present, but this
> would make it considerably easier still for people to introduce new
> nondeterministic failures in projects. Maybe if it were tied to a
> special pipeline type, and then we set it only for the experimental
> pipeline or something?

If it reduces nondeterministic spam for the CI Infra, and makes us
achieve the task at hand, sure.  [/me need to educate himself a
bit more on the Zuul pipeline infrastructure.]

Worth filing this (and your 'idle pipeline' thought below) in the Zuul
tracker here?

    https://storyboard.openstack.org/#!/project/679

> > >  2. the ability to request this recheck to run multiple
> > >     times in parallel. eg if i just repeat the 'recheck'
> > >     command many times on the same patchset # without
> > >     waiting for results
> > 
> > Yes, this too, would be _very_ useful for all the reasons you described.
> [...]
> 
> In the past we've discussed the option of having an "idle pipeline"
> which repeatedly runs specified jobs only when there are unused
> resources available, so that it doesn't significantly cut into our
> resource pool when we're under high demand but still allows to
> automatically collect a large amount of statistical data.
> 
> Anyway, hopefully James Blair can weigh in on this, since Zuul is
> basically in a feature freeze for a while to limit the number of
> significant changes we'll need to forward-port into the v3 branch.
> We'd want to discuss these new features in the context of Zuul v3
> instead.

> -- 
> Jeremy Stanley
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
/kashyap



More information about the OpenStack-dev mailing list