It is really amazing how fast Ansible is developed lately. Stable versions are released more often and contain more changes required by IT professionals. Many of them fill the gaps between two worlds – the developers and operations engineers. Unfortunately, some modules are not catching up as fast as they should which causes problems in developing simple tasks. I experienced such when I was working on playbook example required for my latest press articles for ‘IT Professional’ magazine. The default Ansible junos_facts module couldn’t correctly read JunOS version on some devices. Usually on devices running the older firmware release. This can be a real problem if some tasks execution depends on the firmware version on the router or switch.

Besides the official modules and lots of roles available on Ansible Galaxy repository many vendors developed their own modules and let them use for free. In many cases, it should be considered a better, more secure approach as long as the vendor repository is still maintained. In my situation it was the easiest workaround of my problem.

When the facts do not contain the version number

Ansible has the built-in module supporting several operations on Juniper devices running the JunOS firmware. Sometimes you may experience strange problems – I described one interesting case in my ‘Automated scripts can send commands faster than RP can process‘ post.

If you are working with the Ansible, you should already be familiar with the definition of ‘facts‘. Shortly – facts are the basic pieces of information discoverable about the remote devices recorded as a structure. Check the documentation for more details. For network devices, we need to use a dedicated task to gather facts. Standard Ansible library contains the task ‘junos_facts’ for this purpose. If we use it, the firmware version should be recorded as the “ansible_net_version” value, but if you try it on a device running an older firmware version, like 12.1, you may get the ‘unknown’ as recorded value. It will cause problems if you try to use it as a parameter in the next tasks.

Vendors support for Ansible

If you are a Juniper user, you are the lucky one! Juniper develops their own Ansible library. It is official, free and supported product available via Ansible Galaxy as a role. The source code is available on GitHub as well. If you experience problems the issue tracker let you report it. The installation is as simple as the ‘ansible-galaxy install juniper.junos’ command execution on the host and account where you execute the playbook. Of course, you need to ad ‘Juniper.junos’ role to your playbook as well. Tasks from the Juniper library starts with the ‘juniper_junos’ to differentiate them from the ‘junos_’ tasks from official Ansible library.

Juniper added their own task to gather facts from the device. To run it you need to call the ‘juniper_junos_facts’ module in the task and provide the variable name for the output as a ‘register’ parameter. 

---
- name: Some JunOS playbook
  hosts: all
  connection: netconf
  gather_facts: no
  roles:
    - Juniper.junos

  tasks:
    - name: Gather the facts
      juniper_junos_facts:
      register: my_junos_facts

You will find the firmware version recorded under the ‘my_junos_facts.ansible_facts.junos.version’ key.

So far I found no problems in reading the version number correctly using the Juniper library.