Toshio Kuratomi 9dda393d70

* Build documentation for Ansible-2.10 (formerly known as ACD).

Builds plugin docs from collections whose source is on galaxy

The new command downloads collections from galaxy, then finds the
plugins inside of them to get the documentation for those plugins.

* Update the python syntax checks
  * docs builds can now require python 3.6+.

* Move plugin formatter code out to an external tool, antsibull-docs.
  Collection owners want to be able to extract docs for their own
  websites as well.
* The jinja2 filters, tests, and other support code have moved to antsibull
* Remove document_plugins as that has now been integrated into antsibull-docs

* Cleanup and bugfix to other build script code:
  * The Commands class needed to have its metaclass set for abstractmethod
    to work correctly
  * Fix lint issues in some command plugins

* Add the docs/docsite/rst/collections to .gitignore as
  everything in that directory will be generated so we don't want any of
  it saved in the git repository
* gitignore the build dir and remove edit docs link on module pages

* Add docs/rst/collections as a directory to remove on make clean
* Split the collections docs from the main docs

* remove version and edit on github
* remove version banner for just collections
* clarify examples need collection keyword defined

* Remove references to plugin documentation locations that no longer exist.
  * Perhaps the pages in plugins/*.rst should be deprecated
    altogether and their content moved?
  * If not, perhaps we want to rephrase and link into the collection
    documentation?
  * Or perhaps we want to link to the plugins which are present in
    collections/ansible/builtin?

* Remove PYTHONPATH from the build-ansible calls
  One of the design goals of the build-ansible.py script was for it to
  automatically set its library path to include the checkout of ansible
  and the library of code to implement itself.  Because it automatically
  includes the checkout of ansible, we don't need to set PYTHONPATH in
  the Makefile any longer.

* Create a command to only build ansible-base plugin docs
  * When building docs for devel, only build the ansible-base docs for
    now.  This is because antsibull needs support for building a "devel
    tree" of docs.  This can be changed once that is implemented
  * When building docs for the sanity tests, only build the ansible-base
    plugin docs for now.  Those are the docs which are in this repo so
    that seems appropriate for now.

2020-07-17 13:07:35 -07:00

3.4 KiB

Raw Blame History

Callback Plugins

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.

Example callback plugins

The log_plays <log_plays_callback> callback is an example of how to record playbook events to a log file, and the mail <mail_callback> callback sends email on playbook failures.

The say <say_callback> callback responds with computer synthesized speech in relation to playbook events.

Enabling callback plugins

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 <ansible_configuration_settings>.

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 2_second.py.

Most callbacks shipped with Ansible are disabled by default and need to be whitelisted in your ansible.cfg <ansible_configuration_settings> file in order to function. For example:

#callback_whitelist = timer, mail, profile_roles, collection_namespace.collection_name.custom_callback

Setting a callback plugin for `ansible-playbook`

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 <ansible_configuration_settings>. For example:

stdout_callback = dense

or for my custom callback:

stdout_callback = mycallback

This only affects ansible-playbook by default.

Setting a callback plugin for ad-hoc commands

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:

[defaults]
bin_ansible_callbacks=True

You can also set this as an environment variable:

export ANSIBLE_LOAD_CALLBACK_PLUGINS=1

Plugin list

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.

action_plugins: Ansible Action plugins
cache_plugins: Ansible cache plugins
connection_plugins: Ansible connection plugins
inventory_plugins: Ansible inventory plugins
shell_plugins: Ansible Shell plugins
strategy_plugins: Ansible Strategy plugins
vars_plugins: Ansible Vars plugins
User Mailing List: Have a question? Stop by the google group!
webchat.freenode.net: #ansible IRC chat channel

3.4 KiB Raw Blame History