Callbacks are places in Ansible execution that can be plugged into for added functionality. There are expected callback points that can be registered against to trigger custom actions at those points. Here is a list of possible points to trigger functionality at the time of writing:

• v2_on_any
• v2_runner_on_failed
• v2_runner_on_ok
• v2_runner_on_skipped
• v2_runner_on_unreachable
• v2_runner_on_no_hosts
• v2_runner_on_async_poll
• v2_runner_on_async_ok
• v2_runner_on_async_failed
• v2_runner_on_file_diff
• v2_playbook_on_start
• v2_playbook_on_notify
• v2_playbook_on_no_hosts_matched
• v2_playbook_on_no_hosts_remaining
• v2_playbook_on_task_start
• v2_playbook_on_cleanup_task_start
• v2_playbook_on_handler_task_start
• v2_playbook_on_vars_prompt
• v2_playbook_on_setup
• v2_playbook_on_import_for_host
• v2_playbook_on_not_import_for_host
• v2_playbook_on_play_start
• v2_playbook_on_stats
• v2_on_file_diff
• v2_playbook_on_include
• v2_runner_item_on_ok
• v2_runner_item_on_failed
• v2_runner_item_on_skipped
• v2_runner_retry

As an Ansible run reaches each of these states, any plugins that have code to run at these points will be executed. This provides the tremendous ability to extend Ansible without having to modify the base code.

Callbacks can be utilized in a variety of ways: to change how things are displayed on screen, to update a central status system of progress, to implement a global locking system, or nearly anything imaginable. It's the most powerful way to extend the functionality of Ansible. To demonstrate our ability to develop a callback plugin, we'll create a simple plugin that will print something silly on the screen as a playbook executes:

1. First, we'll need to make a new directory to hold our callback. The location Ansible will look for is callback_plugins/. Unlike the filter plugin earlier, we do need to name our callback plugin file carefully, as it will also have to be reflected in an ansible.cfg file.
2. We'll name ours callback_plugins/shrug.py. Inside this file, we'll need to create a CallbackModule class, subclassed from CallbackModule, defined in the default callback plugin found in ansible.plugins.callback.default, since we only need to change one aspect of the normal output.
3. Within this class, we define variable values to indicate that it is a 2.0 version callback, and that it is an stdout type of callback, finally, that it has the name shrug.
4. Also within this class, we define one or more of the callback points we'd like to plug into in order to make something happen.
5. We only have to define the points we want to plug in. In our case, we'll plug into the v2_on_any point so that our plugin runs at every callback spot:

from ansible.plugins.callback import default
class CallbackModule(default.CallbackModule):
  CALLBACK_VERSION = 2.0
  CALLBACK_TYPE = 'stdout'
  CALLBACK_NAME = 'shrug'
  def v2_on_any(self, *args, **kwargs):
    msg = 'xc2xaf\_(xe3x83x84)_/xc2xaf'
    self._display.display(msg.decode('utf-8') * 8)

6. As this callback is stdout_callback, we'll need to create an ansible.cfg file and, within it, indicate that the shrug stdout callback should be used. The ansible.cfg file can be found in /etc/ansible/ or in the same directory as the playbook:

[defaults] 
stdout_callback = shrug 

7. That's all we have to write into our callback. Once it's saved, we can rerun our previous playbook, which exercised our sample_filter, but this time we'll see something different on the screen:

This is very silly, but it demonstrates the ability to plug into various points of a playbook execution. We chose to display a series of shrugs on screen, but we could have just as easily interacted with some internal audit and control system to record actions, or to report progress to an IRC or Slack channel.