Introduction
Before getting started, I wanted to take the time to address the elephant in the room… how do we even pronounce pyATS? In short, it’s pie-A-T-S. However, the pyATS team has this nice visual on their site:
Now that we are all on the same page, let’s start looking at pyATS and how it fits into the network automation landscape.
“A piece of the pie”
I recently had a “Meet the Engineer” discussion with JB (@jeaubin5 on Twitter) from the pyATS dev team and we talked about the different “domains” that make up a proper network automation ecosystem and ultimately how pyATS fits into it. I always refer back to this visual from a session I attended at Cisco Live 2019 in San Diego.
Each slice of the pie represents a domain in the ecosystem. If you’re just starting your network automation journey, I’m sure you’ve heard of or played with many of the tools found in the ‘Configuration Management’ domain. This domain is by far the most popular when it comes to network automation. Besides having an abundance of tools available, this domain is popular due to the number use cases it can help solve. Most of the time, network engineers begin looking at network automation when they have a proper use case or problem they’re trying to solve. Most of the time, that use case revolves around pushing out configuration at scale. This may be pushing out a mass configuration update or ensuring that devices are adhering to a “golden configuration”. However, this really shouldn’t be how you begin your network automation journey…
As with trying anything new in networking, or tech as a whole, you want to start testing with changes that have the lowest risk and impact. These changes are most of the time read-only and do not affect the configuration or operational state of a device. I think most engineers can agree with the previous statements… so why do we not take the same approach with network automation? To be fair, configuration management can be limited to only collecting and parsing out configuration (no configuration changes). However, most of the time, many use cases revolve around pushing out configuration (i.e. updating an ACL, global configuration (NTP, DNS, etc.), or simply adding a VLAN to a group of switches). Let’s start our network automation journey the right way by discovering how our network is really operating before pushing out any potential breaking changes. We will begin by diving into the ‘Stateful Test & Validation’ piece of the pie.
What’s pyATS?
Before pyATS was released to the public in late 2017, the ‘Stateful Test & Validation’ domain was pretty bare. At that time, much of the focus was around configuration management, which made sense. Configuration management was a long standing problem for many network teams, so solving that problem was a huge and quick win. Fast-forward to the present, infrastructure-as-code and automation as a whole has taken off. We are beginning to view and manage our networks through git repositories instead of SSH sessions. With this rapid adoption of automation, network engineers had begun figuring out that network automation went beyond just mass configuration pushes or config management. We could begin collecting data from the network via MDT, logs, parsed ‘show’ output, etc. and be able to tell exactly how the network is running and how it reacts to specific changes. Wouldn’t it be great knowing that all the routers across your environment had a certain number of BGP neighbors and their associated uptime? Have you ever wondered if that one switchport was down before and after the software upgrade? Wouldn’t it be great to mock up a configuration change, create testcases on specific criteria (i.e. number of routing adjacencies, CPU/memory %, etc.), and confirm it works before pushing it out to hundreds of devices? These are only a few use cases for a network testing and validation tool. Enter pyATS…
pyATS was initially an internal testing tool for Cisco. It was open sourced and released to the public in late 2017. It creates a base testing framework for other tools and libraries. When many people first hear about pyATS, they also hear about its popular counterpart Genie. Genie is a Python library that builds on top of pyATS and provides the tools for pyATS, including network device APIs, parsers, and much more. Using the metaphor from the pyATS docs, think of pyATS as an empty toolbox and Genie being all the tools to put into it. Here’s a quick visual of how pyATS and Genie work together:
When I first looked into pyATS and Genie, I was confused because I thought they were one product. It wasn’t until I saw the above diagram that I slowly started figuring out the differences between them. I will emphasize that it’s not super important to understand the differences between the two when you’re first starting out since you’ll be using them together, but it will down the road.
Conclusion
I really thought I could fit everything in one post, but the more I read through the pyATS and Genie docs, the more exciting features I found, and I want to make sure I highlight them all properly. I’ll be creating a second post (Part 2) in the next couple weeks to begin highlighting some of these neat features and diving into the technical details. Stay tuned!
In the meantime, if you have any questions/feedback, please feel free to hit me up on Twitter (@devnetdan)!
