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 _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra