Once we have standalone ansible roles, we don't need to embed the
ansible code in the puppet module. We also don't need to delete the
existing roles path, as the follow on standalone role should go in
place, but we want the existing role to exist in the mean time.
Change-Id: I76d5cab55942beaff44ea5f289f93ff6ce772c5f
Roles can contain embedded library code, which is how roles work when
you distribute them on ansible galaxy. Put the library there and remove
the old location to prepare for standalone modules.
Change-Id: Iaa7906f71bb0a3bc255695e72b6ae061407fa2b8
The previous change to make the puppetmaster configurable in the ansible
playbook omitted passing through the parameter in the task. Also, add
the parameter to the module docs.
Change-Id: I6bcd58803fd11c3d64608ea1d9fca269042936b4
With split puppet master infrastructure ansible needs to be told which
puppetmaster to talk to. Do this by making puppetmaster a required
argument to the puppet ansible playbook.
Since we can't rely on the cert listing while this is happening also add
puppet master specific host list files which can be used to specify
which hosts talk to which puppetmaster via the new ansible playbook
feature.
Change-Id: I412c2bd6cb390d00d1b9d0e4630e75776edabbb9
If the logic is just in a role, it's hard to re-use it in a one-off
manner on the command line. By putting it into a module, we can
run:
ansible git0* -m puppet
To run puppet on the git farm, for instance.
Also, the file is completely not openstack specific, so do it in
such a way that we can submit it as a module upstream.
Change-Id: I35b2850e02ec5da2b41ad14eec9fd6d5a356bc93
Instead of a shell script looping over ssh calls, use a simple
ansible playbook. The benefit this gets is that we can then also
script ad-hoc admin tasks either via playbooks or on the command
line. We can also then get rid of the almost entirely unused
salt infrastructure.
Change-Id: I53112bd1f61d94c0521a32016c8a47c8cf9e50f7
Andreas Jaeger