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.
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 ...