Just the facts ma’am.

One of the things about Ansible that makes it so useful, is its ability to gather information about a system that can then be used in the tasks you run.  Because of how the NetApp modules work, this feature isn’t core to them. However, for ONTAP there is the na_ontap_gather_facts module.  This module allows you to gather information about a cluster and use that information in a playbook.   

The module isn’t fully self-explanatory so let’s look at how it works. 

Using the module is the same as any other task. 

*You can actually present the last five lines as an alias.  See https://netapp.io/2018/10/12/getting-started-with-netapp-and-ansible-complete-workflow/ for an explanation of how to do that.  

When this task runs it collects a large amount of information in JSON and stores it in the variable ontap_facts.  From here it can be used to gather this information. 

You can use this information to auto select the first aggregate with enough free space.  Assuming that your size_unit is gb the following will loop through aggregates till it finds the first one with enough free space. 

Here the {{ item }} variable will be the name of the aggregate.  This works because we are looping through the results (with_items) for the aggregate_info data.  We are doing checks on each return to see the available size (converted to gb with triple 1024 divides) is larger than the requested size. 

Currently there are a few downsides to this method.  The first being that all aggregates that have enough free space after the first aggregate has been found will print errors to the output, but not interrupt the play, because of the ignore_errors.  The second being that if you add aggregates or rename, or even if the results return in a different order, rerunning this playbook could cause the volume to be migrated to the new first response aggregate. 

There is a lot of data in na_ontap_gather_facts.  I suggest running a playbook via ansible-playbook with a -vvv at the end so you can see for yourself all the returned information.  I would also like to point out that na_ontap_gather_facts was written by Piotr Olczak at Red Hat.  This is an example of a community submitted module that was an excellent addition to our set and became an officially supported NetApp module.   

Piotr, like myself and many of the other module developers, are in #configurationmgmt on our Slack workspace.  Stop by with any Ansible questions you have.  If you don’t have an invite to our Slack get one at www.netapp.io/slack.  Also, be sure to check back frequently at netapp.io for more information on Ansible and our other Open Ecosystem projects. 

David Blackwell on Linkedin
David Blackwell
Technical Marketing Engineer at NetApp
David is a twenty year IT veteran who has been an admin for just about every aspect of a DataCenter at one time or another. When not working, or tinkering with new software at home, David spends most of his free with his four year old son and his lovely wife.

Leave a Reply