Network Automation with Red Hat Ansible Automation Platform

Use conditionals to evaluate the result from a command that is executed on the managed node and then wait for a certain result before continuing.

The following table illustrates the unique conditionals you can use to evaluate the command result in a managed node:

The wait_for command argument can be used to specify one or more conditions to evaluate against the output of the command. The task does not continue to execute until all conditions are true. If the conditions are not true within the configured number of retries, then the task fails.

You can control how many retries to do, and how much time to leave between one and the other. By default, the number of retries is set to 9. Use the retries command argument to modify this value. By default, the interval in seconds between retries is 1. Modify this interval using the interval command argument.

The following example shows a task that runs the show interfaces command on the managed nodes, and then waits for the result of that task to contain the text GigabitEthernet1 is up. It retries the task 19 times, waiting two seconds between each retry.

- name: Wait for the second network interface
  cisco.ios.ios_command:
    commands:
      - show interfaces
    wait_for:
      - result[0] contains 'GigabitEthernet1 is up'
    interval: 2
    retries: 19

When working directly with network devices, sometimes there is a prompt confirmation message that must be answered to perform some actions or changes on the devices. By using Ansible, you can handle these kinds of prompt confirmations using the ansible.netcommon.cli_command module with the prompt parameter.

The prompt parameter is accompanied by the answer parameter. The prompt parameter specifies the prompt message that is received on the network device, or a list of these prompt messages when there are more than one. Likewise, the answer parameter specifies the answers to the prompt.

The value of the prompt parameter must not only match the network device prompt request, but also follow the rules for Python regular expressions, as indicated in https://docs.ansible.com/ansible/latest/network/user_guide/network_working_with_command_output.html#handling-prompts-in-network-modules.

In the following example, the task uses the cisco.ios.ios_command to send the reload command to the managed nodes. Then, the prompt message from the network device and the corresponding answer are specified.

- name: Reboot the managed nodes
  cisco.ios.ios_command:
    commands:
      - command: 'reload'
        prompt: 'Proceed with reload\?'
        answer: 'y'

One of the best ways to simplify debugging playbooks is to follow good practices when writing them in the first place. The following list describes some recommended practices for playbook development:

To help you follow good practices, Red Hat Ansible Automation Platform 2.3 provides a tool called Ansible Lint, which uses a set of predefined rules to look for possible issues with your playbook.

Use the ansible-navigator lint command to review a file for common errors and issues:

[user@host ~]$ ansible-navigator lint playbook.yml

Not all the issues that Ansible Lint reports break your playbook, but a reported issue might indicate the presence of a more serious error. The output provided for the ansible-navigator lint command shows the issue found, the line where the issue was found, and the rule that allowed Ansible Lint to find the issue.

For example, assume that you have the following ios_information.yml playbook:

---
- name: Gather information from IOS devices
  hosts: ios
  gather_facts: false
  tasks:
    - name: Gather information from IOS devices
      ios_command:
        commands:
        - show version
        - show interfaces

Use the ansible-navigator lint command to validate it:

[user@host ~]$ ansible-navigator lint ios_information.yml -m stdout
fqcn[action]: Use FQCN for module actions, such `<namespace>.<collection>.ios_command`. (warning) 
ios_information_lint.yml:7 Action `ios_command` is not FQCN.

yaml[indentation]: Wrong indentation: expected 10 but found 8 
ios_information_lint.yml:10

yaml[trailing-spaces]: Trailing spaces 
ios_information_lint.yml:11

yaml[empty-lines]: Too many blank lines (1 > 0) 
ios_information_lint.yml:12

The ansible-navigator command produces playbook artifact files by default each time you run a playbook. These files record information about the playbook run, and can be used to review the results of the run when it completes, to troubleshoot issues, or be kept for compliance purposes. Each playbook artifact file is named based on the name of the playbook you ran, followed by artifact, and then the time stamp of when the playbook was run, ending with the .json file extension.

For example, if you run the command ansible-navigator run networking.yml at 20:00 UTC on May 31, 2023, the resulting file name of the artifact file would be:

networking-artifact-2023-05-31T20:00:04.019343+00:00.json

You can review the contents of these files with the ansible-navigator replay command. If you include the -m stdout option, then the output of the playbook run is printed to your terminal as if it had just run. If you omit that option, you can examine the results of the run interactively.

Consider the following playbook where you run the show interfaces command on Junos managed nodes. The playbook uses the ansible.netcommon.cli_command module to run the command:

---
- name: Gather interfaces information for Junos devices
  hosts: junos
  gather_facts: false
  tasks:
    - name: Run command on remote managed nodes
      ansible.netcommon.cli_command:
        command: show interfaces

The junos managed nodes were defined in the inventory file for the project:

[junos]
junos[1:2].lab.example.com

[junos:vars]
ansible_user=developer
ansible_ssh_private_key_file=~/.ssh/lab_rsa
ansible_connection=ansible.netcommon.netconf
ansible_network_os=junipernetworks.junos.junos

If you run the playbook then it fails. Using Ansible Lint, you do not find any issues in the predefined rules.

To troubleshoot further, you run ansible-navigator replay in interactive mode on the resulting artifact file, which opens the following output in your terminal:

Figure 3.24: Initial replay screen

You can press 0 to display details of the play. The output shows the failed results in each of the managed nodes. In this case, to simplify and show the problem, the play only has one task. If there is more than one task, they are listed in this output.

Figure 3.25: Play results by managed node and task

It looks like the Run command on remote managed nodes task failed on both managed nodes. By entering 0 or 1 you can see the failure for the first or the second managed node, respectively.

The following terminal output shows the failed result for the first managed node. You find a similar result for the other node.

Figure 3.26: Task results for one of the managed nodes

The task is attempting to use the ansible.netcommon.cli_command module to execute the show interfaces command on the managed node, but the connection type used by this playbook is not valid for that module.

You might discover that the ansible.netcommon.netconf connection type was configured as the default for the Junos managed nodes in the inventory file:

[junos:vars]
ansible_user=developer
ansible_ssh_private_key_file=~/.ssh/lab_rsa
ansible_connection=ansible.netcommon.netconf
ansible_network_os=junipernetworks.junos.junos

Using the same play but with the ansible.netcommon.network_cli connection type, the result is successful on both managed nodes.

Figure 3.27: Successful task results in the managed nodes

ansible-navigator:
  playbook-artifact:
    enable: false

Use the logging key in the ansible-navigator.yml configuration file to set the parameters related to logs that are controlled by automation content navigator.

The following parameters apply to the logging key:

The following example shows an automation content navigator configuration where you specify a debug log level for troubleshooting:

ansible-navigator:
  logging:
    append: true
    file: /tmp/ansible-navigator.log
    level: debug