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
ansible-playbook is in /usr/local, but that's not in the cron job path.
Also, although there is an ansible log setting in ansible.cfg, the
ansible-playbook command still outputs stuff. We don't want cronspam,
so add the redirection to the log file back in.
Change-Id: Id585c11cca4cbd7e1ba26adbfbe22af650ca2b50
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
When we want to watch run_all happen, it's hard, because there is
no logging. To fix that - make there be some logging. Then, rotate
the logs.
Change-Id: I0eed7aeeec0ff21e58d57d6385cc59b74bbf31fb
In anticipation of driving puppet over ssh, we need keys on the hosts
and the scripts on the master. Don't turn them on yet, because we want
to be able to do some by-hand testing of the mechanism.
Change-Id: I2c353777e2f8fb5a2e733ce405ba40427ce901e5
