Tuesday, August 6, 2019

To be or not to be.. using Declarative Intent modules in Ansible?

Declarative Intent modules in Ansible are device specific modules that configure a specific feature on a networking device. Such modules are nxos_bgp, nxos_ntp, iosxr_bgp and several others.

Sounds like a great thing.. there are certain cases that they really help, but when you start digging deeper sometimes you get a not so nice surprise.

Consider the scenario where you want to create several config sections for a device and push them to the device. You have actually two main options

  1. Use multiple Jinja2 templates, create the final config file and push it to the device
  2. Use multiple declarative intent modules, one for each feature you need to configure
Someone might say 'Why should I bother learning Jinja2 and use a template.. Let's go for the easier path using a specific module'. That's what I initially though and started preparing my config using such modules. 

For simple tasks and small playbooks the modules are quite good, but if you start writing more complex ones and use more 'exotic' features, then you'll certainly have problems. That's what I found out:

  • If you want to build a playbook that will create config for several platforms, you will need the respective module for each one of them. Guess what.. There is no parity between platforms for each module. You may find the specific module for nxos, but no module for ios or ios-xr.
  • If you are lucky enough to find the required modules, you realize that one of them supports the vrf option that you need, but the rest don't.
  • If you are still lucky and get to a point where you want to optimize the execution of your playbook, by using  the 'aggregate' option, you realize it's supported only for a few of your modules. For the rest you just wait..
  • If you got to this point you are really lucky and your playbook executes quite well. But then you realize that each module you call, it executes a 'show running-config' on your device. This happens for every module, each time you call it. What if you have a device with long config that takes some time to return? Not so effective, don't you think?
These are some of the problems I got through and so I decided to go with Jinja2 for that playbook. Working with Jinja2 had also some constraints, but the final result was much better.

I'm not saying that declarative intent modules are not useful. Sometimes they certainly help, but don't be fooled, everything comes with a cost..

No comments:

Post a Comment