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

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to