Open Stack

Bogdan Dobrelya <bdobreli at redhat.com> writes:

> 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.

What you're describing sounds more like a job graph within a pipeline.
See: https://docs.openstack.org/infra/zuul/user/config.html#attr-job.dependencies
for how to configure a job to run only after another job has completed.
There is also a facility to pass data between such 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

Creating a job graph to have one job use the results of the previous job
can make sense in a lot of cases.  It doesn't always save *time*
however.

It's worth noting that in OpenStack's Zuul, we have made an explicit
choice not to have long-running integration jobs depend on shorter pep8
or tox jobs, and that's because we value developer time more than CPU
time.  We would rather run all of the tests and return all of the
results so a developer can fix all of the errors as quickly as possible,
rather than forcing an iterative workflow where they have to fix all the
whitespace issues before the CI system will tell them which actual tests
broke.

-Jim