Ansible 2.2 Network Updates

November 1, 2016 by Peter Sprygada

Ansible for Network Automation

The Slack channel question seemed so innocuous at the time, “I was reviewing through the Ansible 2.2 commits related to networking. Is there a summary of the networking items that are new in 2.2?”

In a rather quick response, my first answer seemed so obvious, “Not really, mostly simplifying code, merging template with config modules and some new platforms."

As the conversation continued though, reality came crashing down with the realization that the sprint from Ansible 2.1 to Ansible 2.2 for networking modules was substantially more than a few tweaks and added platforms.

Before getting into what’s new and what’s changed, let's review the overall state of network integration with Ansible. We started this journey just about a year ago announcing that Ansible would start supporting direct integration with network devices. At the time, this was a fairly big departure from the more traditional roots where Ansible has focused on in the systems and application development worlds. There always seemed to be a natural fit between Ansible’s agentless, SSH-based architecture’s ability to adapt to automating traditional network device configurations. It didn’t take long for the initial integration of network modules to start achieving greater adoption.

In just three releases (counting the initial Ansible 2.0 Network Technology Preview), Ansible network modules now comprise 20% of the modules available in core (including extras). That’s quite exciting in and of itself, but it’s just the beginning with some exciting things still to come!

Here's what went into Ansible 2.2 modules and what you can expect from enhancements in the networking modules:

Template modules

Okay, templates aren’t gone...yet. One of the most common questions asked since the initial implementation of network modules has been understanding the difference between template and config. Well, we heard the frustrations loud and clear and as of Ansible 2.2, we have announced the deprecation of template network modules. The modules will continue to function and be available until Ansible 2.4, at which time the modules will be removed.

The reasoning behind the deprecation is to simplify the implementor's choice of which module to use. To that end, the template modules provide functionality and that functionality has been merged into the config modules. This change now provides Playbook designers with a single comprehensive module for working with network device configuration files moving forward.

Speaking of config modules

Adding the additional capabilities of templates isn’t the only changes introduced into the config modules. The config modules continue to add incremental features for managing the active or running-config of remote devices. In addition, the individual network operating system config modules implement specific functionality on a per platform basis.

One of the key features added in Ansible 2.2 is the ability for config modules to now provide an argument for saving the current ephemeral configuration to nonvolatile storage for platforms that require it. Also, some of the arguments have been moved around to better align with the operation being performed. For instance, 'force: yes' has been replaced by 'match: none'. Finally, one of the biggest changes implemented in the config modules is the introduction of using automated rollbacks where available (per platform). For platforms that support rollbacks, the config module will now automatically rollback the configuration if an error is encountered during the configuration push.

More robust commands

Some fairly nice enhancements have also made their way into network command modules. The most significant is the ability for Playbook designers to now specify the command output desired for a given command. For instance, when working with the eos_command module and configuring the transport to cli, all returned commands will be structured text. Commands can now be provided as a list that specifies individually what the desired output format should be.

New platform support

One of the areas that will continue to see lots of growth over the next few releases is platform support. While network modules aren’t attached to specific hardware platforms, modules are developed for specific network operating systems, each with its own quirks, characteristics and nuances. Ansible 2.2 saw network platform support expand to 17 platforms with the addition of support for the following:

Facts modules

Along with helping to clean up much of the confusion around template vs config, perhaps the next biggest requested addition was the ability to get facts from network devices. The initial implementation for fact collection of network devices was twofold.

First, was to provide a framework and implementation for fact collection that was consistent with using the standard setup module in Ansible. With that goal in mind, the network facts implementation provides a base set of facts implemented across supported platforms. The implementation delivers a base set of default facts with an optional subset of facts that can be enabled or disabled. The initial implementation supports fact subsets for hardware, interfaces and config in addition to the default base set of facts.

The second goal was to maintain consistency and availability of facts regardless of the network operating system. While there are some deviations based on how information is presented and gleaned from the underlying operating systems, efforts have been made to standardize fact collection. Going forward, additional facts can more easily be added to network devices.

Community contributions

Perhaps one of the biggest growth areas from 2.1 to 2.2 was the community involvement in cultivating network modules in Ansible. Community contributes to 2.2 outpaced the core team by well over a factor of 3 to 1 in terms of modules committed. In addition, we have added a weekly networking community meeting to discuss issues around Ansible networking modules, review open issues / pending pull requests and overall discuss needs / wants and nice to haves.

The community meeting meets every Wednesday at 1600 UTC on the Freenode IRC channel #ansible-meeting. Everyone in the Ansible community is more than welcome to attend and bring up any topics for consideration around networking integration with Ansible.

More details along with meeting logs and standing agenda can be found at: https://github.com/ansible/community/issues/110

Module testing

A lot of time and effort went into cleaning up the module testing repositories for 2.2. Providing test modules is important for organizations looking to transition Ansible from lab tool to operational tool. By providing the testing Playbooks used to validate network modules, organizations can test against their specific trains of code and specific revisions of hardware. In addition, the module testing Playbooks provide a framework that can be adopted by an organization that is using Ansible and expanded upon to add their own specific test cases.

We are committed to continuing to add more robust testing around network modules. In that regard, one of the key initiatives was to mirror the network test Playbooks to align with Ansible releases. Moving forward, as new releases of Ansible are tagged in the project repositories, there will be equivalent tags in the test Playbook repositories as well. As with all aspects of Ansible, community participation is more than welcome.

Module documentation

Another big effort that often goes unheralded but is nevertheless one of the most important aspects of development is providing more robust documentation. Admittedly there is still more to be done but then again I’m not sure any project has ever suffered from “over documentation.” Over the course of 2.2 development, each of the network module's documentation strings were scoured and scrubbed in an effort to provide useful descriptions for how to use various network modules and what various arguments mean.

Looking ahead

As network integration in Ansible continues to expand, I am excited for the road ahead. Over the course of the last year, we, collectively as an Ansible community, have established a foundation for being able to address integration of configuration automation across IT disciplines. By continuing to address complexity, Ansible’s simple approach and powerful automation language is providing networking teams with a new breed of tools focusing on supporting network operations.

When we started down the path of network integration with Ansible, it was well understood it was going to be long term commitment. In just under a year, we have made exciting strides as a community and looking forward to the coming releases.

Getting started

Getting started with Ansible is easy. After installing Ansible, you’ll soon be automating your network.

Get the latest Ansible release on GitHub.

Read about Ansible networking modules on Ansible Docs.

Explore network integrations with Arista, Cisco, Cumulus, Juniper and more.


Share:

Topics:
Community, Ansible, Networks


 

Peter Sprygada

Peter is a Senior Principal Engineer for Ansible at Red Hat, where he brings over 20 years experience building and operating global network infrastructures. He holds two patents in network configuration automation and currently leads the Ansible network engineering team that focuses on building solutions and integrating network automation use cases into Ansible. You can follow him on twitter at @privateip.


rss-icon  RSS Feed

Ansible Tower by Red Hat
Learn About Ansible Tower