8 Special Modules in Ansible

In this blog post, we introduce you to a selection of Ansible modules that allow you to trigger very specific (mostly internal) actions.

“meta”: Triggering Various Ansible Actions

- name: Quit play

  meta: end_play

The number of available meta-actions has grown steadily over the years. Ansible 2.12 and later know the following nine actions:

• clear_facts: This deletes facts and the facts cache.
• clear_host_errors: This is very misleading―it merely brings unreachable hosts back on board, and only if there is still a host left.
• end_host: This ends the play for the current host (without error).
• end_play: This ends the play for all hosts (without error). You should not associate end_play with host-specific conditions (e.g., when: inventory_hostname == "server27"). If you do, the behavior will become quite unpredictable and you will not achieve what you intended. You should use end_host for this purpose!
• flush_handlers: This causes “premature” invocation of handlers.
• noop: This does nothing (which is necessary sometimes).
• refresh_inventory: This triggers a reload of the inventory (which only makes sense with dynamic inventories).
• reset_connection: This discards the persistent SSH connections so that any subsequent tasks will establish new connections.
• end_batch: This ends the current batch. With serial: 0 or undefined, the effect is identical to end_play. The online documentation for this is here.

“debug”: Generating Output during Playbook Runs

- debug: msg="Hello"

- debug: var=ansible_default_ipv4

The naming of these tasks with name is often omitted, if only because a debug task often should not remain in the play. Using the var parameter helps when you want to show the contents of a variable easily.

The online documentation for this is found here.

“fail”: Triggering a Failure

- set_fact:

  hour: ""

- fail:

  msg: "It is simply too late today."

when: hour|int > 20

With the fail module, you can deliberately trigger a failure and thus end the play for the respective hosts. In the old days of Ansible, before meta: end_play was invented, this was the only way to exit a play.

The online documentation for this is here.

“pause”: Pausing and Optionally Reading Input

- pause:

  prompt: Please turn off the lights now

- name: Give the CPU time to cool down

  pause:

      seconds: 30

- pause:

      prompt: Please enter your name

  register: this

- debug: msg="Goodbye !"

With the pause module, you can stop the execution of a playbook for a period of time.

Attention: Please do not use pause to wait for interactive input if your playbook might run in noninteractive environments like Cron or Ansible AWX/Tower!

The online documentation for this is at this link.

“wait_for”: Waiting for Certain Events

- name: Wait until the file /tmp/foo is present

  wait_for:

      path: /tmp/foo

- name: Wait 300 seconds for port 8000 to become open

  wait_for:

      port: 8000

With the wait_for module, you can wait in the play until a certain condition is met. The maximum wait time is 300 seconds by default (with the timeout parameter). In addition to the possibilities shown here, you can wait for a port to close or you can compare file contents or sockets with a regular expression and wait until the pattern matches. The online documentation for this is found here.

“wait_for_connection”: Waiting Until a Target Host Is Reachable

- name: Wait 600 seconds for target connection to become reachable/usable

   wait_for_connection:

       timeout: 600

The timeout of 600 seconds is the default and therefore does not need to be specified separately.

The online documentation for this is here.

“assert”: Ensuring that Certain Conditions Are Met

- name: It must be Debian 9 or 10

  assert:

      that:

          - ansible_distribution == "Debian"

          - ansible_distribution_major_version is version('9', '>=')

          - ansible_distribution_major_version is version('10', '<=')

      fail_msg: "Only Debian version 9 or 10 is supported"

The assert module ensures that all specified conditions are met; otherwise, processing is aborted with an error. The online documentation for this is at this link.

“set_fact”: Setting Variables during Runtime

- name: Set two variables

  set_fact:

      foo: 100

      bar: 200

- debug: msg="foo = , bar = "

With set_fact, you can set host-specific variables at runtime.

The online documentation for this is at this link.

Editor’s note: This post has been adapted from a section of the book Ansible: The Practical Guide for Administrators and DevOps Teams by Axel Miesen. Axel is an Ansible coach. His interest in Linux systems began with his studies at the University of Kaiserslautern, where he studied mathematics and computer science. After graduating in 1998, he began working as a consultant and trainer and has passed on his Linux knowledge and experience to numerous professionals.

This post was originally published 8/2025.