Network Automation with Red Hat Ansible Automation Platform

By default, if a task fails, the play is aborted. However, this behavior can be overridden by ignoring failed tasks. You can use the ignore_errors keyword in a task to accomplish this.

The following example shows how to use ignore_errors in a task to continue playbook execution on the managed node even if the task fails. If the virtual LAN (VLAN) with ID 150 does not exist, then the cisco.ios.ios_command module fails, but having ignore_errors set to true enables execution to continue.

tasks:
  - name: Displaying VLAN id 150 information
    cisco.ios.ios_command:
      commands:
        - show vlan id 150
    ignore_errors: true

You can use the failed_when keyword on a task to specify the conditions that indicate a failed task. This is often used with command modules that might successfully execute a command on the managed node, but where the command output indicates a failure.

For example, you can execute a command on the managed node that outputs a message that you can consider an error, and then use that message to define the failed state for the task. The following example shows how you can use the failed_when keyword in a task:

tasks:
  - name: Displaying configured VLANs
    cisco.ios.ios_command:
      commands: show vlans
    register: vlan_result
    failed_when: "'No Virtual LANs configured' in vlan_result['stdout'][0]"

You can use the ansible.builtin.fail module to force a task failure. You can also use that module to provide a custom failure message for the task.

For example, you can modify the previous example as follows, where the tasks produce the failure and send a customized message when you run the playbook:

tasks:
  - name: Displaying configured VLANs
    cisco.ios.ios_command:
      commands: show vlans
    register: vlan_result

  - name: Reporting command failure
    ansible.builtin.fail:
      msg: "Missing VLAN configuration"
    when: "'No Virtual LANs configured' in vlan_result['stdout'][0]"

When a task makes a change to a managed node, it reports a task result of changed. However, sometimes tasks are performed outside of the managed node and you might not want this change to be reported on the managed node.

You can use the changed_when keyword to control how a task reports that it has changed something on the managed node. If you set the value of the changed_when keyword to false, then the task never reports a changed state.

For example, the Copying the vlan configuration to a file task in the following example gathers information from the managed node, but does not change any configuration on the managed node:

tasks:
  - name: Gather IOS interface facts
    cisco.ios.ios_facts:
      gather_network_resources: vlans

  - name: Copying the vlan configuration to a file
    ansible.builtin.copy:
      content: "{{ ansible_network_resources['vlans'] | to_nice_yaml }}"
      dest: "{{ inventory_hostname }}_vlan.yml"
      mode: 0600

When you run the playbook for the first time, the task reports a changed result for each managed node against which the task runs:

TASK [Copying the vlan configuration to a file] ********************************
changed: [iosxe1]
changed: [iosxe2]
changed: [iosxe3]

The following example shows how to use the changed_when keyword in a task to never report the changed result:

tasks:
  - name: Gather IOS interface facts
    cisco.ios.ios_facts:
      gather_network_resources: vlans

  - name: Copying the vlan configuration to a file
    ansible.builtin.copy:
      content: "{{ ansible_network_resources['vlans'] | to_nice_yaml }}"
      dest: "{{ inventory_hostname }}_vlan.yml"
      mode: 0600
    changed_when: false