pyATS Blitz configure is used in test automation to apply configuration, verify behavior, and optionally remove the configuration afterward. . This lesson also demonstrates how to handle interactive prompts using the reply section in a Blitz YAML file, allowing automated responses when the device expects input, such as confirmations or names.

pyATS Blitz Configure and Prompt Handling

In the previous lessons, we explored several PyATS Blitz actions, including execute, parse, and learn. In this lesson, we will continue our discussion on PyATS Blitz by focusing on the configure action and how to handle interactive prompts during test automation.

pyATS Blitz Configure action and Prompt Handling
pyATS Blitz Configure action and Prompt Handling

The configure action is used to send configuration commands to a network device via the CLI. It is commonly used in test scenarios where temporary configuration changes are needed — for example, disabling an interface to test redundancy and then restoring the original configuration afterward.

As for prompt handling, some configuration commands may trigger interactive prompts from the device (e.g., confirmation messages like “Do you want to continue? [yes/no]:”). Blitz allows us to handle such prompts using the reply section in the YAML file. This enables the test script to automatically respond to the prompt — such as confirming a save operation before making changes, or responding to file transfer confirmations when copying files to an FTP server.

pyATS Blitz Configure Action

In this example, the Blitz test case Testcase1 includes a section named configure_commands, where the configure action is used to send CLI configuration commands to the device R1. Specifically, it enables OSPF process 6 and sets the router ID to 1.1.1.1. This demonstrates how the configure action in pyATS Blitz can be used to apply routing configurations to a network device as part of an automated test.

Testcase1:
  test_sections:
    - configure_commands:
      - configure:
          device: R1
          command: |
              router ospf 6
              router-id 1.1.1.1

After running the script, the configure action successfully applied a new OSPF configuration on device R1, creating router ospf 6 with the router ID 1.1.1.1, as shown in the CLI output. Although the configuration step itself passed, the final test result marked the section as failed because the post-test configuration did not match the original snapshot taken at the beginning of the test. This difference was correctly detected by Genie, which reported the addition of the new OSPF process as a deviation. The final configuration confirms that both router ospf 1 (pre-existing) and the newly added router ospf 6 are now present on R1, indicating that the test modified the device configuration without reverting the changes.

# before running script
R1#show running-config | sec router ospf
router ospf 1
 network 10.13.0.0 0.0.255.255 area 0
R1#
...
2025-06-30T09:30:07: %AETEST-INFO: :                     Starting STEP 1.1: Configuring 'R1'                      :
2025-06-30T09:30:07: %AETEST-INFO: +..............................................................................+

2025-06-30 09:30:07,875: %UNICON-INFO: +++ R1 with via 'cli': configure +++
config term
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router ospf 6
R1(config-router)#router-id 1.1.1.1
R1(config-router)#end
R1#
2025-06-30T09:30:08: %AETEST-INFO: The result of STEP 1.1: Configuring 'R1' is => PASSED
2025-06-30T09:30:08: %AETEST-INFO: The result of STEP 1: Starting action configure on device 'R1' is => PASSED
...
2025-06-30T09:30:08: %GENIE-INFO:  | * Summary for device: R1                                                                                                                           |
2025-06-30T09:30:08: %GENIE-ERROR: |     - Comparison between original configuration taken at common setup and the one taken at common cleanup is different as per the following diffs: |
2025-06-30T09:30:08: %GENIE-ERROR: | +router ospf 6                                                                                                                                     |
2025-06-30T09:30:08: %GENIE-ERROR: | + router-id 1.1.1.1                                                                                                                                |
2025-06-30T09:30:08: %GENIE-INFO:  |****************************************************************************************************************************************************|
2025-06-30T09:30:08: %GENIE-INFO:  | * Summary for device: R2                                                                                                                           |
2025-06-30T09:30:08: %GENIE-INFO:  |     - Comparison between original configuration taken at common setup and OPS object snapshots are equal                                           |
2025-06-30T09:30:08: %GENIE-INFO:  |****************************************************************************************************************************************************|
2025-06-30T09:30:08: %GENIE-INFO:

2025-06-30T09:30:08: %AETEST-ERROR: Failed reason: Comparison of Configuration in Common Setup and Common Cleanup has been modified.  Check the summary table for more details
2025-06-30T09:30:08: %AETEST-INFO: The result of subsection verify_configuration_snapshot is => FAILED
...
# after running script
R1#show running-config | sec router ospf
router ospf 1
 network 10.13.0.0 0.0.255.255 area 0
router ospf 6
 router-id 1.1.1.1
R1#

pyATS Blitz Parallel Action

Th Blitz Action Parallel in pyATS allows you to run multiple Blitz actions in parallel across multiple devices. This is useful when you’re testing scenarios involving simultaneous configuration, failover testing, or multi-device verification — and want to reduce execution time by not running actions sequentially.

This pyATS Blitz YAML file defines a test case named Testcase1 that demonstrates the use of the parallel action to run multiple configuration tasks simultaneously. Within the test_sections, two configure actions are executed in parallel: the first configures device R1 with an NTP server (1.1.1.1), and the second configures device R2 with an SNMP community string (public). By using the parallel block, both configuration commands are sent concurrently, which can improve efficiency and simulate real-time multi-device scenarios during network test automation.

(majid) majid@majid-ubuntu:~/devnet/pyats$ cat 9.7.blitz_parallel.yaml
Testcase1:
  test_sections:
    - parallel:
      - configure:
          device: R1
          command: ntp server 1.1.1.1
      - configure:
          device: R2
          command: snmp-server community public

The execution result shows that both configuration actions — adding an NTP server on device R1 and setting an SNMP community string on device R2 — were successfully executed and passed. Although defined in a parallel block, the logs display each action sequentially due to how output is logged, but both devices received and applied their respective configurations without errors, resulting in a fully passed test case.

...
2025-06-30T09:35:49: %AETEST-INFO: :          Starting STEP 1: Starting action configure on device 'R1'           :
2025-06-30T09:35:49: %AETEST-INFO: +..............................................................................+
2025-06-30T09:35:49: %AETEST-INFO: +..............................................................................+
2025-06-30T09:35:49: %AETEST-INFO: :                     Starting STEP 1.1: Configuring 'R1'                      :
2025-06-30T09:35:49: %AETEST-INFO: +..............................................................................+

2025-06-30 09:35:49,870: %UNICON-INFO: +++ R1 with via 'cli': configure +++
config term
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ntp server 1.1.1.1
R1(config)#end
R1#
2025-06-30T09:35:50: %AETEST-INFO: The result of STEP 1.1: Configuring 'R1' is => PASSED
2025-06-30T09:35:50: %AETEST-INFO: The result of STEP 1: Starting action configure on device 'R1' is => PASSED
2025-06-30T09:35:50: %AETEST-INFO: +..............................................................................+
2025-06-30T09:35:50: %AETEST-INFO: :          Starting STEP 2: Starting action configure on device 'R2'           :
2025-06-30T09:35:50: %AETEST-INFO: +..............................................................................+
2025-06-30T09:35:50: %AETEST-INFO: +..............................................................................+
2025-06-30T09:35:50: %AETEST-INFO: :                     Starting STEP 2.1: Configuring 'R2'                      :
2025-06-30T09:35:50: %AETEST-INFO: +..............................................................................+

2025-06-30 09:35:50,069: %UNICON-INFO: +++ R2 with via 'cli': configure +++
config term
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#snmp-server community public
R2(config)#end
R2#
2025-06-30T09:35:50: %AETEST-INFO: The result of STEP 2.1: Configuring 'R2' is => PASSED
2025-06-30T09:35:50: %AETEST-INFO: The result of STEP 2: Starting action configure on device 'R2' is => PASSED

pyATS Blitz Prompt Handling

Prompt handling in pyATS Blitz allows automated responses to interactive CLI prompts during test execution. When a device command expects user input (e.g., confirmation prompts), the reply section is used to match the prompt pattern and automatically send the appropriate response.

In this example, the Blitz test sends the write erase command to device R1, which typically prompts for confirmation. The reply section matches the prompt Continue? [confirm]? and responds with y, enabling the command to complete without manual intervention — fully automating the interaction.

(majid) majid@majid-ubuntu:~/devnet/pyats$ cat 9.3.blitz_execute_prompt_handling.yaml
Testcase1:
  trigger_uids:
    - Testcase1
  test_sections:
    - execute_commands:
        - execute:
            device: R1
            command: write erase
            reply:
              - pattern: .*Continue\? \[confirm\]\?
                action: sendline(y)

The result shows that the write erase command on device R1 was successfully executed and the confirmation prompt (Continue? [confirm]) was automatically handled by the reply section. The configured response (y) was correctly sent, allowing the command to proceed and complete the NVRAM erase. As a result, the step passed, demonstrating that prompt handling in pyATS Blitz worked as expected.

...
2025-06-30T09:12:42: %AETEST-INFO: :              Starting STEP 1.1: Executing 'write erase' on 'R1'              :
2025-06-30T09:12:42: %AETEST-INFO: +..............................................................................+

2025-06-30 09:12:42,285: %UNICON-INFO: +++ R1 with via 'cli': executing command 'write erase' +++
write erase
Erasing the nvram filesystem will remove all configuration files! Continue? [confirm]
[OK]
Erase of nvram: complete
R1#
2025-06-30T09:12:42: %AETEST-INFO: The result of STEP 1.1: Executing 'write erase' on 'R1' is => PASSED
...
Back to: Network Automation with pyATS & Genie (in Progress) > pyATS Blitz

Leave a Reply

Your email address will not be published. Required fields are marked *


Post comment