Validate idempotency

The best playbooks are idempotent playbooks

More about Modules

Modules do the actual work in Ansible, they are what gets executed in each playbook task.
- Typically written in Python (but not limited to it)
- Modules can be idempotent
- Modules take user input in the form of parameters

Network modules

Ansible modules for network automation typically references the vendor OS followed by the module name.
- namespace.collection.facts
- namespace.collection.command
- namespace.collection.config
- namespace.collection.resource
For example:
- Arista EOS = arista.eos.
- Cisco IOS/IOS-XE = cisco.ios.
- Juniper Junos = junipsnetworks.junos.

Lets get started

That is the end of of your lab briefing!

Step 1 - Validate idempotency

The cisco.ios.config module is idempotent. This means, a configuration change is pushed to the device if and only if that configuration does not exist on the end hosts.

Need help with Ansible Automation terminology?= Check out the glossary here for more information on terms like idempotency.

To validate the concept of idempotency, re-run the playbook:

ansible-navigator run playbook.yml --mode stdout

See that the changed parameter in the PLAY RECAP indicates 0 changes.

Re-running the Ansible Playbook multiple times will result in the same exact output, with ok=1 and change=0. Unless another operator or process removes or modifies the existing configuration on rtr1, this Ansible Playbook will just keep reporting ok=1 indicating that the configuration already exists and is configured correctly on the network device.

Step 2 - Modify Ansible Playbook

Now update the task to add one more SNMP RO community string named ansible-test.
Use code-server to open the playbook.yml file to add the command:
```
- snmp-server community ansible-test RO
```
Make sure to save the playbook.yml with the change.

Step 3 - Use check mode

This time however, instead of running the playbook to push the change to the device, execute it using the --check flag in combination with the -v or verbose mode flag:

ansible-navigator run playbook.yml --mode stdout --check -v

The --check mode in combination with the --verbose flag will display the exact changes that will be deployed to the end device without actually pushing the change. This is a great technique to validate the changes you are about to push to a device before pushing it.

Step 4 - Verify configuration is not present

Verify that the Ansible Playbook did not apply the ansible-test community. Login to cisco and check the running configuration on the Cisco IOS-XE device.
```
ssh cisco
```
```
show run | i snmp
```
Output should look like the following:
```
snmp-server community ansible-public RO
snmp-server community ansible-private RW
```
```
exit
```

Step 5 - Re-run the Ansible Playbook

Finally re-run this playbook again without the -v or --check flag to push the changes.
```
ansible-navigator run playbook.yml --mode stdout
```

Step 6 - Verify Config is present

Feel free to cut and paste the following command.

ssh cisco

sh run | i snmp

Output should look like the following:

snmp-server community ansible-public RO
snmp-server community ansible-private RW
snmp-server community ansible-test RO

exit

Takeaways

The config (e.g. cisco.ios.config) modules are idempotent, meaning they are stateful
check mode ensures the Ansible Playbook does not make any changes on the remote systems
verbose mode allows us to see more output to the terminal window, including which commands would be applied
This Ansible Playbook could be scheduled in Automation controller to enforce the configuration. For example this could mean the Ansible Playbook could be run once a day for a particular network. In combination with check mode this could just be a read only Ansible Playbook that sees and reports if configuration is missing or modified on the network.

--Complete--