19ea4603f4
It turns out you can't use "run_once" with the "free" strategy in Ansible. It actually warns you about this, if you're looking in the right place. The existing run-puppet role calls two things with "run_once:", both delegated to localhost -- cloning the ansible-role-puppet repo (so we can include_role: puppet) and installing the puppet modules (via install-ansible-roles role), which are copied from bridge to the remote side and run by ansible-role-puppet. With remote_puppet_else.yaml we are running all the puppet hosts at once with the "free" strategy. This means that these two tasks, both delegated to localhost (bridge) are actually running for every host. install-ansible-roles does a git clone, and thus we often see one of the clones bailing out with a git locking error, because the other host is running similtaneously. I8585a1af2dcc294c0e61fc45d9febb044e42151d tried to stop this with "run_once:" -- but as noted because it's running under the "free" strategy this is silently ignored. To get around this, split out the two copying steps into a new role "puppet-setup". To maintain the namespace, the "run-puppet" module is renamed to "puppet-run". Before each call of (now) "puppet-run", make sure we run "puppet-setup" just on localhost. Remove the run_once and delegation on "install-ansible-roles"; because this is now called from the playbook with localhost context. Change-Id: I3b1cea5a25974f56ea9202e252af7b8420f4adc9 |
||
|---|---|---|
| .. | ||
| tasks | ||
| README.rst | ||
Run puppet on remote servers
Omnibus role that takes care of installing puppet and then running puppet. Uses include_role so that the installation of the puppet role can run as the first task, then the puppet role can be used in a following task.
This role should run after puppet-setup-ansible