Open Stack

Antoine Musso <hashar at free.fr> writes:

> Something worry me, is that the Zuul scheduler layout file might end
> up very long and complicated since it will define both the workflow
> and the tasks with their context.  The later is currently done in
> Jenkins jobs

Thanks for your thoughts.  You make a good point, our current layout
file is very long.

I am imagining that the new configuration would be broken up into more
files -- not only by tenant, but we could separate it into files for
particular projects, or even include all files in a directory (there's
work in progress to add this to the current version of Zuul).

Also, keep in mind that in-repo configuration might also further make
the configuration partitioned and comprehensible.

> On this list Monty had the idea to teach JJB to generate Ansible tasks
> in addition to the Jenkins XML configuration files.  I have seen a
> patch in JJB to expand the JJB YAML definitions, essentially producing
> a YAML per job. Each can surely be converted to an Ansible task and be
> made available on the nodes.
>
> One can surely write a tiny zuul-worker client that would execute on
> the node, register to the Gearman bus and expose all ansible tasks it
> is able to run.  Such a worker could be isolated in a virtual env to
> avoid dependencies conflicts.

Yes, this is the direction we have been heading with Zuul v2, however, I
think there are three good reasons to adopt the ansible worker approach
I described:

1) Multi-node jobs are easier to describe.  As we have started doing
multi-node work, we have found that it is awkward to orchestrate a
multi-job config from one of the workers itself.

2) When orchestrating things in production, the process usually executes
from outside of the orchestration space -- it's easier to map that into
the CI realm if we can maintain the same approach -- and this can
promote sharing of code between CI and CD.

3) Logging into the worker nodes over SSH, rather than requiring direct
connectivity to gearman from them, makes it easier to run Zuul in a
private network and expand into a public cloud for worker resources.
This is not strictly necessary for OpenStack's instance, but it would
help other users.

Finally, I think that the rest of the work I'm proposing around job
definitions (including inheritance, etc), mean that all of the complex
templating in JJB will not be required in Zuul.  We have 4986 Jenkins
jobs in OpenStack, but because of the extreme use of templating, we only
have 236 unique definitions, and 55 of those are devstack-gate jobs
which could almost certainly be templated more efficiently.

The overall configuration of the system (what the jobs are and when to
run them) should be about the same size as it is now.  But I think it
will be better organized and easier to reason about -- users will not
have to bridge the gap between the two tools in their minds in order to
understand the whole system.

-Jim