This is the second post in the series on Napalm validation in which we will explore more options available to us for writing validation tests. First part can be found here: NAPALM-Ansible - Automatic validation - part 1. First we'll make amendments to YAML files we used to describe desired LLDP state and see how it affects validation results. After that we'll introduce two more examples, one for checking BGP peerings, and one for verifying reported interfaces. Contents Partial string matching and regex BGP peering validation example Strict mode and 'list' key Listings of Playbooks GitHub repository with resources for...
Tag: Playbook
Network automation is not just about configuration management. Equally, if not more, important is validation of the state and models. After all, what is automating configuration changes good for if you don't know whether the end state of the system is correct? In the first blog post in the series I'll briefly describe Napalm, and it's validation feature, followed by an example Ansible playbook that we will use to automatically validate LLDP neighbours. This can be used to makes sure newly deployed devices are correctly patched, or to confirm that the existing environment is connected the way we think it...
Let's talk about passing extra Playbook variables from command line. First off, why would you want to do it? Maybe you want to execute task only if a variable is defined, which is handy for debugs and tasks with additional processing. Or maybe you have a more generic playbook that can work with more than one version of OS, and you want your user to decide which one OS he wants to run Playbook for. I will show in this post how we can tackle both of these problems. Contents Introduction to extra variables Execute task when variable is defined...
When running tasks Ansible allows you to access facts about host currently being processed. These could be facts discovered by Ansible itself or loaded from the files in the host_vars directory. This is something that we use all the time and is fairly intuitive. Sooner or later you will probably find out that some of your tasks, or data models, could be made simpler if you could access another host's facts, not just the ones belonging to the host Ansible is currently processing. As it happens, this is possible by using something Ansible calls magic variables. The particular variable...
While using loops in Ansible, by default, output contains the entire content of the item being processed. This can result in a great amount of verbosity if the item is a dictionary or is otherwise long. For example, when looping through the output of the "show ip bgp sum", we want to use just an IP of the peer as an input in another task. When "Get routes for each of the BGP peers" task executes Ansible will display the entire data structure linked to that peer. Task with the loop: - name: Get routes for...