Automating StorageGRID with Ansible makes it easy to run common workflows quickly, consistently, and at scale. Tasks that would normally require clicking through the Grid Manager UI can be codified, repeated, and version-controlled. However, automation quickly runs into a common problem: many workflows require information that isn’t known ahead of time.
IDs for storage pools, tenants, users, ILM components, and other resources are generated per grid and differ between environments. Hard-coding these values defeats the purpose of automation and makes playbooks brittle, environment-specific, and difficult to reuse.
This is where the StorageGRID information modules—na_sg_grid_info and na_sg_org_info—become essential. These modules allow Ansible to dynamically query the Grid Manager or Tenant Manager APIs, gather the current state of the system, and expose that information for use in subsequent tasks. The grid module collects information at the Grid Manager level, while the org module focuses on tenant-level data.
Gathering this information is straightforward, but effectively using it is often less obvious. The returned data is structured JSON, and knowing how to reference the right fields is key to building flexible, reusable playbooks. The examples below walk through how to collect grid information, inspect the returned data, and extract specific values—such as storage pool IDs—that are commonly required for tasks like building ILM rules and policies.
Lets look at a simple playbook that runs the ‘grid’ information collection.
---
- name: Data Look up
hosts: localhost
gather_facts: false
vars:
grid_user: root
grid_password: <password>
grid_address: https://<yourgrid>
tasks:
- name: generate auth token for grid module on StorageGRID
netapp.storagegrid.na_sg_grid_login:
hostname: "{{ grid_address }}"
username: "{{ grid_user }}"
password: "{{ grid_password }}"
validate_certs: false
register: auth
- name: Gather GRID info
netapp.storagegrid.na_sg_grid_info:
api_url: "{{ grid_address }}"
auth_token: "{{ auth.na_sa_token }}"
validate_certs: false
register: sg_info
If you need a reference on how to use the grid_login module see my last post on this topic - StorageGRID Automation: A Resolution You Can Keep - NetApp Community
Using the ‘register’ line at the bottom saves all the returned information to a variable called ‘sg_pool_info’. With this any of the information can be accessed and used. The format for would look like this.
“{{ sg_info.sg_info[‘grid/<subset>’] }}”
Here ‘sg_info’ is a dictionary that is keyed by the different subsets
Subset can be any of the following.
accounts
alarms
audit
compliance-global
config
config/management
config/product-version
deactivated-features
dns-servers
domain-names
ec-profiles
expansion
expansion/nodes
expansion/sites
firewall-blocked-ports
firewall-external-ports
firewall-privileged-ips
gateway_configs
grid-networks
groups
ha-groups
health
health/topology
identity-source
ilm-criteria
ilm-grade-site
ilm-grades
ilm-policies
ilm-pools
ilm-rules
license
management-certificate
network-topology
ntp-servers
recovery
recovery/available-nodes
regions
schemes
single-sign-on
snmp
storage-api-certificate
untrusted-client-network
users
users/root
versions
vlan-interfaces
As you can see a vast amount of information is available. Gathering each of these takes time, and usually will be unused data. For this reason the ‘gather_subset’ option exits. For example when making ILM rules with Ansible, the ID of the storage pool is required and this data is in the subset ilm-pools. We can gather just the ilm-pool information like this.
- name: Gather pool ID
netapp.storagegrid.na_sg_grid_info:
api_url: "{{ grid_address }}"
auth_token: "{{ auth.na_sa_token }}"
validate_certs: false
gather_subset:
- grid_ilm_storage_pools_info
register: sg_pool_info
I also changed the variable name that I register the information as to make it easier to track.
Getting specific information requires understanding the json format of the subset. For example when making ILM rules with Ansible, the ID of the storage pool is required and this data is in the subset ilm-pools.
On an example grid this information looks like this.
"grid/ilm-pools": {
"apiVersion": "4.2",
"data": [
{
"archives": [],
"disks": [
{
"grade": null,
"group": 10,
"siteId": "bbf88845-a108-4210-8869-6c33465eccfc"
}
],
"displayName": "gdl",
"id": "p9829506629192568060",
"name": "gdl"
}
],
"responseTime": "2026-01-23T16:20:39.930Z",
"status": "success",
"status_code": 200
},
This is an easy example to use because there is only one storage pool. To reference the ID of this pool the variable would look like this.
"{{ sg_pool_info.sg_info['grid/ilm-pools'].data[0].id }}"
This example assumes a grid with a single storage pool. In environments with multiple pools, you would filter the data list based on name or siteId.
So that’s the grid/ilm-pools subset, in that the ‘data’ section and the [0] means the first entry since unix counts from 0 instead of from 1. The .id specifies that is the field that we want. Outputs can be tested with the debug module
- name: info test
debug:
msg: "{{ sg_pool_info.sg_info['grid/ilm-pools'].data[0].id }}"
This will print ‘p9829506629192568060’ to the screen.
You can find the Ansible modules in either Ansible Galaxy Collections or in Ansible Automation Platform as certified modules. Be sure to check back next month for an example of building an ILM rule set and policy using these techniques.
