Open Stack

On 26/02/15 17:59, James E. Blair wrote:
> A new Zuul component would be created to execute jobs.  Rather than
> running a worker process on each node (which requires installing
> software on the test node, and establishing and maintaining network
> connectivity back to Zuul, and the ability to coordinate actions across
> nodes for multi-node tests), this new component will accept jobs from
> Zuul, and for each one, write an ansible inventory file with the node
> and variable information, and then execute the ansible playbook for that
> job.  This means that the new Zuul component will maintain ssh
> connections to all hosts currently running a job.  This could become a
> bottleneck, but ansible and ssh have been known to scale to a large
> number of simultaneous hosts, and this component may be scaled
> horizontally.  It should be simple enough that it could even be
> automatically scaled if needed.  In turn, however, this does make node
> configuration simpler (test nodes need only have an ssh public key
> installed) and makes tests behave more like deployment.

Hello James,

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

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.

This way the layout.yaml remains simple, you can reuse all the jobs 
definitions and people can write pure ansible task if need be.

My 0.02 cents

-- 
Antoine Musso