[openstack-dev] [TripleO] Planning for job execution outside the gate with Zuul v3

James E. Blair corvus at inaugust.com
Mon Nov 20 23:38:08 UTC 2017


David Moreau Simard <dms at redhat.com> writes:

> 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
> different repositories.
> For example, the Zuul v3 from review.rdoproject.org can selectively include
> parts of git.openstack.org/openstack-infra/tripleo-ci [1] 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.

Thanks for starting this thread!  I think it's a great idea.

I'd just like to mention here for folks who may not be aware --
re-usability of this kind is an explicit design goal of Zuul v3.  We're
hoping that the zuul-jobs repo in particular can be used by any Zuul in
the world to run the same job content.  In fact, the core review team
on that repo has already grown to include contributors from outside the
OpenStack ecosystem altogether.

The openstack-zuul-jobs and other individual repos may also provide job
content that's usable by folks operating Zuuls related to OpenStack
(e.g., third-party CI operators and distributors, as is the case here).

And finally, at the very least, if jobs themselves aren't re-usable, we
hope that the Ansible roles they use will be re-usable.  It is for this
reason that we have focused heavily on role development with simplified
playbooks in the common Zuul v3 jobs so far.

-Jim



More information about the OpenStack-dev mailing list