When I started working with Ansible networking modules they had a distinct science fair feel: everything was in flux, every new version of Ansible would break my playbooks, modules would disappear from one release to next, documentation was sketchy and describing the latest development code not a shipped release.

In the meantime, code, documentation, and release/deprecation management improved dramatically:

• Features that still need a shake-out are clearly marked as preview;
• Documentation is available for individual releases starting with release 2.5 (the current shipping release is 2.7);
• They wrote excellent getting started and connectivity troubleshooting guides.

What I found most important though is the stability of older programming interfaces.

Since release 2.3 the networking team rapidly moved through five programming/connectivity paradigms:

• Specify username, password and transport options on every module invocation (later introducing provider parameter to reduce the verbosity)
• Specify username and password using standard Ansible mechanisms;
• Replace per-invocation SSH sessions with persistent SSH sessions, increasing performance but severely hampering debugging… until they got it right two releases or so later;
• Replace local connection hack with network_cli connection plugin which implemented only SSH transport. NETCONF and REST transports still needed local connection to work.
• Add httpapi and netconf connection plugins for devices that understand more than CLI, finally bringing some feature completeness into networking modules.

But that’s not all… networking modules couldn’t possibly use the standard privilege escalation mechanisms forever available in Ansible, so there’s an extra migration step in case you want to switch the way your playbook enters enable mode (because they finally decided that networking devices aren't that special ;).

The early changes caused tons of headaches, but I was pleasantly surprised when digging through network_cli and networking modules code when preparing for the update sessions I ran in January and February 2019: at that time all networking modules still supported local connection and even provider parameters. Not only that, all the device-facing code is abstracted into a common library - Ansible networking team did a great job creating just the right abstraction layer to keep the old playbooks working while at the same time simplifying module developers’ life.

The rapid evolution of ideas does present an interesting challenge to people like me trying to help network engineers cope with the realities of network automation: do you focus them on latest-and-greatest features, or on something else that looks a bit outdated but happens to be robust and stable?

I always prefer robust and stable over latest fad, be it in networking design or in network automation, so I waited a bit for the dust to settle before updating my Ansible materials. Obviously some $vendors hate me for saying that out loud, but I couldn’t care less – our audience are customer networking engineers trying to make sense out of madness not vendor marketers.

---

Interested in what we’re doing? Check out Ansible for Networking Engineers and other network automation materials, and when you’re ready to start your automation journey for real join the Building Network Automation Solutions online course.