When targeting localhost with 'remote_user: root' and
using 'become: yes' we lose the environment variables
for the user running the playbook (eg: USER, HOME).
However, if we use 'connection: local' and 'become: yes'
together, it works properly.
To ensure these plays have the correct access to change
things on the host, we apply this change to them all.
We also ensure that 'become: no' is explicitly set on
any local connection plays to make the intent more
obvious. Finally, we also use 'yes' and 'no' uniformly.
Change-Id: I6e4607dd4aaffa0bfcda254103697bf9b28eca1a
When using remote_user and delegation to localhost we
do not have access to change anything on the file system
that the user running the playbook (zuul) does not have.
For now we work around this by using 'become: yes' again
so that everything runs as root, much like was done for
several other plays in https://review.openstack.org/580156
Change-Id: I2fbb0785a3179b4213c999344c35e52637fe3f1f
It makes no sense to use become when you're connecting to a
host via the root remote_user. As such, we remove all uses of
'become: true' from the test plays with the exception of the
'test-prepare-keys.yml' playbook which uses a local connection
rather than a remote one and it therefore needs to use become.
We also transition all plays to use 'remote_user' which is the
correct parameter to replace 'user' (since ansible 1.4).
Finally, we switch the horizon nova service setup to its own
playbook using a local connection and the upstream keystone
modules.
Change-Id: I20517c22f07b1bb811a51d8c63741604360fe7f8
Sometimes a test will result in a failure, but it
takes more time than necessary to find the failure
due to Ansible continuing to execute on other hosts
after removing one from the play execution.
This patch ensures that any error will result in
an immediate failure so that the fatal error is
easier to find.
Change-Id: I4e89bfdb1e48d0ac65f9fb8549e55a19ab773f9f
In order to effectively test rolling upgrades, haproxy
will need to be installed to facilitate the services
being online while the upgrades are happening.
The common task to manage the backend when doing
rolling upgrades is included.
The keystone install playbook makes use of them both
in order to facilitate the rolling upgrades.
Change-Id: I5cbb3824430dc09b36476f81e0cdfd4f0a15f497