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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
