[openstack-dev] [TripleO] Planning for job execution outside the gate with Zuul v3
David Moreau Simard
dms at redhat.com
Mon Nov 20 22:31:51 UTC 2017
As the migration of review.rdoproject.org to Zuul v3 draws closer, I'd like
to open up the discussion around how we want to approach an eventual
migration to Zuul v3 outside the gate.
I'd like to take this opportunity to allow ourselves to think outside the
box, think about how we would like to shape the CI of TripleO from upstream
to the product and then iterate to reach that goal.
The reason why I mention "outside the gate" is because one of the features
of Zuul v3 is to dynamically construct its configuration by including
For example, the Zuul v3 from review.rdoproject.org can selectively include
parts of git.openstack.org/openstack-infra/tripleo-ci  and it will load
the configuration found there for jobs, nodesets, projects, etc.
This opens a great deal of opportunities for sharing content or
centralizing the different playbooks, roles and job parameters in one
single repository rather than spread across different repositories across
the production chain.
If we do things right, this could give us the ability to run the same jobs
(which can be customized with parameters depending on the environment,
release, scenario, etc.) from the upstream gate down to
review.rdoproject.org and the later productization steps.
There's pros and cons to the idea, but this is just an example of what we
can do with Zuul v3.
Another example of an interesting thought from Sagi is to boot virtual
machines directly with pre-built images instead of installing the
undercloud/overcloud every time.
Something else to think about is how can we leverage all the Ansible things
from TripleO Quickstart in Zuul v3 natively.
There's of course constraints about what we can and can't do in the
upstream gate... but let's avoid prematurely blocking ourselves and try to
think about what we want to do ideally and figure out if, and how, we can
Whether it's about the things that we would like to do, can't do, or the
things that don't work, I'm sure the feedback and outcome of this could
prove useful to improve Zuul.
How would everyone like to proceed ? Should we start an etherpad ? Do some
"design dession" meetings ?
I'm willing to help get the ball rolling and spearhead the effort but this
is a community effort :)
David Moreau Simard
Senior Software Engineer | OpenStack RDO
dmsimard = [irc, github, twitter]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev