Callback plugins enable adding new behaviors to Ansible when responding to events. By default, callback plugins control most of the output you see when running the command line programs, but can also be used to add additional output, integrate with other tools and marshall the events to a storage backend.
The log_plays callback is an example of how to record playbook events to a log file, and the mail callback sends email on playbook failures.
The say callback responds with computer synthesized speech in relation to playbook events.
You can activate a custom callback by either dropping it into a
callback_plugins directory adjacent to your play, inside a role, or by putting it in one of the callback directory sources configured in ansible.cfg.
Plugins are loaded in alphanumeric order. For example, a plugin implemented in a file named
1_first.py would run before a plugin file named
Most callbacks shipped with Ansible are disabled by default and need to be whitelisted in your ansible.cfg file in order to function. For example:
#callback_whitelist = timer, mail, profile_roles, collection_namespace.collection_name.custom_callback
You can only have one plugin be the main manager of your console output. If you want to replace the default, you should define CALLBACK_TYPE = stdout in the subclass and then configure the stdout plugin in ansible.cfg. For example:
stdout_callback = dense
or for my custom callback:
stdout_callback = mycallback
This only affects ansible-playbook by default.
The ansible ad hoc command specifically uses a different callback plugin for stdout, so there is an extra setting in Ansible Configuration Settings you need to add to use the stdout callback defined above:
You can also set this as an environment variable:
You can use
ansible-doc -t callback -l to see the list of available plugins. Use
ansible-doc -t callback <plugin name> to see specific documents and examples.
© 2012–2018 Michael DeHaan
© 2018–2019 Red Hat, Inc.
Licensed under the GNU General Public License version 3.