Mastering Ansible

Chapter 1
Once Ansible parses the patterns, it will then apply restrictions, if any. Restrictions
come in the form of limits or failed hosts. This result is stored for the duration of
the play, and it is accessible via the play_hosts variable. As each task is executed,
this data is consulted and an additional restriction may be placed upon it to handle
serial operations. As failures are encountered, either failure to connect or a failure
in execute tasks, the failed host is placed in a restriction list so that the host will
be bypassed in the next task. If, at any time, a host selection routine gets restricted
down to zero hosts, the play execution will stop with an error. A caveat here is that
if the play is configured to have a max_fail_precentage or any_errors_fatal
parameter, then the playbook execution stops immediately after the task where this
condition is met.
Play and task names
While not strictly necessary, it is a good practice to label your plays and tasks with
names. These names will show up in the command line output of ansible-playbook,
and will show up in the log file if ansible-playbook is directed to log to a file. Task
names also come in handy to direct ansible-playbook to start at a specific task and to
reference handlers.
There are two main points to consider when naming plays and tasks:
• Names of plays and tasks should be unique
• Beware of what kind of variables can be used in play and task names
Naming plays and tasks uniquely is a best practice in general that will help to
quickly identify where a problematic task may reside in your hierarchy of playbooks,
roles, task files, handlers, and so on. Uniqueness is more important when notifying
a handler or when starting at a specific task. When task names have duplicates, the
behavior of Ansible may be nondeterministic or at least not obvious.
[ 19 ]