-e or --execute [1] allows to execute a specific piece of Puppet code
such a class.
For example, in puppet you would run:
puppet apply -e 'include ::mymodule'
Will be in ansible:
puppet: execute='include ::mymodule'
[1] http://docs.puppetlabs.com/puppet/latest/reference/man/apply.html#OPTIONS
While returning puppet logs as ansible stdout is useful in some cases,
there are also cases where it's more destructive than helpful. For
those, local logging to syslog so that the ansible logging makes sense
is very useful.
This defaults to stdout so that behavior does not change for people.
Some do not use the json module directly so don't need import json.
Some needed to fallback to simplejson with no traceback if neither was installed
Fixes#1298
Infra has been keeping a local copy of this waiting for ansible 2 to
release. In getting ready for ansible 2 (and our ability to delete our
local copy of the file, I noticed we had a couple of minor cleanups.
Also, the timeout command is there to improve life and workaround puppet
deficiencies. However, it's not working around deficiencies on systems
that do not have the timeout command if we blindly use it.
The puppet specific timeout options are more complex and out of scope of
this.
Issue: #1273
This was originally to match what puppet agent --test is, since the
rest of the options defaulted to on are grabbed from --test. However,
some security concerns have since been raised - namely that since this
is not the same invocation as --test but instead a remote orchestration
of puppet, the fact that passwords leak into the diff is a dangerous
default.
This reverts commit b86762c180.
puppetmaster was used to determine if `agent` or `apply` should be used. But puppetmaster is not required by puppet per default. Puppet may have a config or could find out by itself (...) where the puppet master is.
It changed the code so we only use `apply` if a manifest was passed, otherwise we use `agent`.
This also fixes the example, which did not work the way without this change.
~~~
# Run puppet agent and fail if anything goes wrong
- puppet
~~~
puppet may be configured to operate in `--noop` mode per default.
That is why we must pass a `--no-noop` to make sure, changes are going to be applied.
There is a growing pattern for using ansible to orchestrate runs of
existing puppet code. For instance, the OpenStack Infrastructure team
started using ansible for this very reason. It also turns out that
successfully running puppet and interpreting success or failure is
harder than you'd expect, thus warranting a module and not just a shell
command.
This is ported in from
http://git.openstack.org/cgit/openstack-infra/ansible-puppet
