published

pyATS-checks-os

Leveragging pyATS and Genie to check run pre_checks and post_check on a testbed.

Installing the requirements

pyATS supports Python versions from 3.5 to 3.8 (i.e. 3.9 is not yet supported). You can check the latest information here:

https://pubhub.devnetcloud.com/media/pyats-getting-started/docs/install/installpyATS.html

pip install -r requirements.txt
touch sqlite/db/checks.db
python sqlite/init_database.py

First line will install the right librairies.
Second and third line will create and initiate the database with the right tables and headers.

Code versions

Below the release notes for each version. You can download an older version here.

v1.0

  • Initial version.

v1.1

  • Minor update, mainly bug fixes.
  • Adding the README documentation for pre_checks and post_checks.

v1.2

  • Minor update, mainly bug fixes.

v1.3

  • Minor update, mainly bug fixes.

v1.4

  • In the pre_checks we are now verifying the Rommon files as well.
  • Adding a few error handlings (ex: empty Genie output before folder does not exist).

v1.5

  • Adding the support for devices with 2 RSP.
  • Adding a check to verify the commands boot system bootflash:/... are pushed, and in the right order.
  • If the VRF doesn't exist on the device before and after, the test is Passed.

v1.6

  • Documentation update
    • ./documentation/README* has been updated,
    • Adding ./documentation/USECASE.md to describe the use case,
    • Added the supported python release for pyATS.

v1.7

  • rommon files can be put in a specific folder (not always the root folder),
  • Documentation has been updated accordingly.

v1.8

  • fixing dual RSP issue. Device has two RSP slots but only one of the two RSP is inserted.

v1.9

  • Adding a check for CPU utilisation for the last 5 minutes.

Using the scripts

Testbed

The two below scripts below (pre_checks and post_checks) will use a testbed file, with all the information about the devices we will verify. Information will include elements such as:

  • IP address,
  • Port,
  • Credentials,
  • Protocol (SSH, telnet),
  • Type of device.

A sample testbed file is provided: ./testbed_template.yaml. You can read the documentation on how to create a testbed file, here:

https://pubhub.devnetcloud.com/media/pyats-getting-started/docs/quickstart/manageconnections.html#creating-testbed-yaml-file

Pre-checks

python pre_checks.py --testbed /link/to/testbed.yaml

Complete details are explained here.

Post-checks

python post_checks.py --testbed /link/to/testbed.yaml

Complete details are explained here.

Printing the diff

To be used after the migration, in case you need to print a specific output, or compare an output before and after the migration.

python check_diff.py --hostname "device_hostname" --testname "test_name" --when "when_tested"
  • --hostname is the complete hostname of the device, as saved in the database.
  • --testname is the name of the test. On the left, the testname, on the right the related IOS XE command:
    • route_summary > show ip route summary
    • routes > show ip route
    • isis > show ip isis neighbors
    • xconnect > show xconnect all
    • cpu > show cpu processes
  • --when is when the test has been run.
    • both > for a diff before/after
    • after > for a specific output after
    • before > for a specific output before

Toolbox

The toolbox includes multiple librairies to clarify the code.

  • database.py: includes all functions relating to database interaction.
    • Getting outputs from the DB.
    • Adding outputs to the DB.
  • pyats_checks.py: contains all the check functions.
    • Leveraging Genie Parsers to extract a specific output, and saving it to the database.
    • Leveraging the database.py library to compare before/after outputs for a given hostname and test_name.
    • Printting the recap table.
  • pyats_diff.py: leveraging the Genie Diff library to highlight differences for a given hostname and test_name.

Database

We use SQLite3 to store and retrieve information. Table schemes are stored in the table-scheme folder.

Testbed

The devices used in the scripts must be added to a testbed.yaml file. A testbed_template.yaml file is provided as example.

Testbed file examples can also be found in the official documentation.

https://pubhub.devnetcloud.com/media/pyats/docs/topology/example.html

Demo

Demo - Check OS

Pre_checks

An example of the expected output can be found here.

Post_checks

An example of the expected output can be found here.

pyATS documentation

The official pyATS documentation is available on the link below.

https://pubhub.devnetcloud.com/media/pyats/docs/index.html

AETest documentation

AEtest (Automation Easy Testing) is the standard test engineering automation harness. It offers a simple and straight-forward way for users to define, execute and debug testcases and testscripts, serving as a basis for other testscript templates & engines.

The official AETest documentation is available on the link below.

https://pubhub.devnetcloud.com/media/pyats/docs/aetest/introduction.html

Difference between FAIL and ERROR

Except is configured differently, if a test is FAIL, it will continue with the next tests. If a test is ERROR it will move directly to the CommonCleanup section.

Complete documentation can be found here:

https://pubhub.devnetcloud.com/media/pyats/docs/aetest/control.html

Use Case

Automating OS migration pre-checks and post-checks with pyATS

Leveragging pyATS and Genie to check run pre_checks and post_check on a testbed.

Migrating from one OS version to the next is not always easy. It can get even more complex when you are running a service provider network, and you have 350 units to upgrade.

This page is an overview of the use case. Complete details are explained in the README here.

This project can be found on DevNet Automation Exchange: it provides shared code repositories for gathering information from your network, performing audits, activating policy changes, or managing applications, users, or devices. This file serves as a template to collect related links for Automation Exchange submissions.

Backbone of the script

This repo contains three scripts that ease the migration : pre_checks, post_checks and check_diff, detailed below.

Pre-checks

To be run before the migration. Run a defined set of tests, and save each output in the database.

python pre_checks.py --testbed /link/to/testbed.yaml

Complete details are explained here.

Post-checks

To be run after the migration. Run a defined set of tests, and save each output in the database.

python post_checks.py --testbed /link/to/testbed.yaml

Complete details are explained here.

Printing the diff

To be used after the migration, in case you need to print a specific output, or compare an output before and after the migration.

python check_diff.py --hostname "device_hostname" --testname "test_name" --when "when_tested"
  • --hostname is the complete hostname of the device, as saved in the database.
  • --testname is the name of the test. On the left, the testname, on the right the related IOS XE command:
    • route_summary > show ip route summary
    • routes > show ip route
    • isis > show ip isis neighbors
    • xconnect > show xconnect all
  • --when is when the test has been run.
    • both > for a diff before/after
    • after > for a specific output after
    • before > for a specific output before

White Paper

pyATS community on Webex

You can join the pyATS community by clicking here.

You can sign up, or create a Webex account here.

pyATS documentation

The official pyATS documentation is available on the link below.

https://pubhub.devnetcloud.com/media/pyats/docs/index.html

AETest documentation

AEtest (Automation Easy Testing) is the standard test engineering automation harness. It offers a simple and straight-forward way for users to define, execute and debug testcases and testscripts, serving as a basis for other testscript templates & engines.

The official AETest documentation is available on the link below.

https://pubhub.devnetcloud.com/media/pyats/docs/aetest/introduction.html

Related Sandbox

You can use the DevNet IOS XE sandbox (or a physical device) in order to run the code. You can find DevNet sandboxes here.

For instance, you can use the always-on IOS XE sandbox.

Please note that you might need to adapt the device configuration in order to run all the tests successfuly. For example, you might need to configure a few ISIS neighbors and xconnects. You might also need to adapt certain variables such as the current OS version. Please refer to the documentation, above.

You can refer to this page which lists all available Learning Labs on pyATS and related subjects.

You can also refer to this repo which includes 5 hands-on exercices on pyATS and Genie.

Solutions on Ecosystem Exchange

You can find other pyATS related projects on DevNet Automation Exchange.

View code on GitHub

Code Exchange Community

Get help, share code, and collaborate with other developers in the Code Exchange community.View Community
Disclaimer:
Cisco provides Code Exchange for convenience and informational purposes only, with no support of any kind. This page contains information and links from third-party websites that are governed by their own separate terms. Reference to a project or contributor on this page does not imply any affiliation with or endorsement by Cisco.