4d7a824070
This patch effectively works around an issue we're seeing with
Ansible's var precedence with the "include -- with_first_found"
pattern.
TL;DR of what is happening is that a role, configure-unbound, has a
"vars" directory which is meant to be used by an "include_vars --
with_first_found" task.
However, since we have a "vars" directory at the playbook level, this
directory has precedence over the one in the role. This makes it so
the var files from the playbook directory are included instead of the
one in the role.
We wanted to address that by using {{ role_path }} within roles, but
it turns out that Zuul's protection mechanisms is actually
interfering [1]. Work around this for the time being.
Since this is all not very straightforward, it ought to be documented
properly somewhere -- this is in the README.rst file for the time
being. Let's figure out a better place later.
[1]: http://eavesdrop.openstack.org/irclogs/%23zuul/%23zuul.2018-01-15.log.html#t2018-01-15T22:44:13
Change-Id: Ia79a793200fcb89161783ff641b85106936084b5
1.0 KiB
1.0 KiB
multinode_firewall_persistence_vars
This directory is meant to contain distribution specific variables
used in integration tests for the
multinode_firewall_persistence role.
The behavior of the with_first_found lookup used with
the include_vars module will make it search for the
vars directory in the "usual" order of precedence which
means if there is a vars directory inside the playbook
directory, it will search there first.
This can result in one of two issues:
- If you try to prepend
{{ role_path }}to workaround this issue with the variable file paths, Zuul will deny the lookup if you are running an untrusted playbook because the role was prepared in a trusted location and Ansible is trying to search outside the work root as a result. - The variables included are the wrong ones -- the ones from
playbooks/varsare loaded instead ofpath/to/<role>/vars
This is why this directory is called
multinode_firewall_persistence_vars.