Open Stack

On Wed, Mar 8, 2017, at 07:20 AM, Paul Belanger wrote:
> 
> Greetings,
> 
> Allow me to bring to your attention a series of patches which create our
> first
> zuulv3 jobs. Specifically, we are looking to discuss what a generic tox
> job in
> ansible will look like.
> 
> Currently, we have 2 proposed patches for zuul (feature/zuulv3) branch
> available:
> 
> Generic tox (single playbook)
> - https://review.openstack.org/438281
> 
> Generic tox (multi playbook)
> - https://review.openstack.org/442180
> 
> Starting with 438281, the main differences lay within the .zuul.yaml
> file. As
> you can see by looking at the code, we are not defining any variables
> (vars) in
> .zuul.yaml. This means, we create 3 separate playbooks (tox-cover.yaml, 
> tox-py27, tox-linters.yaml) which then contain the variables we need for
> our tox
> role.
> 
> With 442180, we move our tox role variables into .zuul.yaml (vars
> section) and
> use a single playbook (tox.yaml) as our entry point for each job.
> 
> Everything else between the 2 patches is the same. So, with that in mind,
> which
> patch do people prefer?

I agree with others that have said both setups are readable and
understandable. I do have a slight preference for the multi playbook
approach as that treats the .zuul.yaml as a very high level overview of
what jobs should be run so you can get a sense for things easily without
worrying about implementation details.

Judging on how our JJB configs have evolved over time I am sure these
will evolve and change as well. So probably best to just pick one and
use it for a bit and go from there (with my slight preference being
multi playbook to start).

Also reading these job defs and comparing against the zuulv3 spec it
isn't clear to me what the expected behavior for inheriting pre and post
playbooks is. Seems like maybe pre is a queue so parent pre roles run
first and post is a stack so parent post roles run last? If that is
already written down and I am just missing it sorry for the noise, if it
isn't written down maybe we can do that?

Thanks,
Clark