[openstack-dev] [ci][infra][tripleo] Multi-staged check pipelines for Zuul v3 proposal

Bogdan Dobrelya bdobreli at redhat.com
Fri Mar 2 13:47:25 UTC 2018


Hello.
As Zuul documentation [0] explains, the names "check", "gate", and 
"post"  may be altered for more advanced pipelines. Is it doable to 
introduce, for particular openstack projects, multiple check 
stages/steps as check-1, check-2 and so on? And is it possible to make 
the consequent steps reusing environments from the previous steps 
finished with?

Narrowing down to tripleo CI scope, the problem I'd want we to solve 
with this "virtual RFE", and using such multi-staged check pipelines, is 
reducing (ideally, de-duplicating) some of the common steps for existing 
CI jobs.

For example, we may want to omit running all of the OVB or multinode 
(non-upgrade) jobs deploying overclouds, when the *undercloud* fails to 
install. This case makes even more sense, when undercloud is deployed 
from the same heat templates (aka Containerized Undercloud) and uses the 
same packages and containers images, as overcloud would do! Or, maybe, 
just stop the world, when tox failed at the step1 and do nothing more, 
as it makes very little sense to run anything else (IMO), if the patch 
can never be gated with a failed tox check anyway...

What I propose here, is to think and discuss, and come up with an RFE, 
either for tripleo, or zuul, or both, of the following scenarios 
(examples are tripleo/RDO CI specific, though you can think of other use 
cases ofc!):

case A. No deduplication, simple multi-staged check pipeline:

* check-1: syntax only, lint/tox
* check-2 : undercloud install with heat and containers
* check-3 : undercloud install with heat and containers, build overcloud 
images (if not multinode job type), deploy overcloud... (repeats OVB 
jobs as is, basically)

case B. Full de-duplication scenario (consequent steps re-use the 
previous steps results, building "on-top"):

* check-1: syntax only, lint/tox
* check-2 : undercloud unstall, reuses nothing from the step1 prolly
* check-3 : build overcloud images, if not multinode job type, extends 
stage 2
* check-4:  deploy overcloud, extends stages 2/3
* check-5: upgrade undercloud, extends stage 2
* check-6: upgrade overcloud, extends stage 4
(looking into future...)
* check-7: deploy openshift/k8s on openstack and do e2e/conformance et 
al, extends either stage 4 or 6

I believe even the simplest 'case A' would reduce the zuul queues for 
tripleo CI dramatically. What do you think folks? See also PTG tripleo 
CI notes [1].

[0] https://docs.openstack.org/infra/zuul/user/concepts.html
[1] https://etherpad.openstack.org/p/tripleo-ptg-ci

-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando



More information about the OpenStack-dev mailing list