Introduction
Infrastructure teams increasingly expect storage management to fit the same automation model they use for servers, networks, cloud services, and applications. NetApp Console local deployment customers can now bring that model to their on-premises and air-gapped environments with the netapp.console Ansible collection, available from Ansible Galaxy.
The first Galaxy release, version 1.0.0, exposes 26 purpose-built modules for automating NCL REST APIs. Together with ready-to-run playbooks and variable templates in the NetApp PACE repository, the collection helps teams move repeatable NCL administration from manual UI workflows and one-off scripts into version-controlled, auditable infrastructure as code.
This is an important distinction: the collection does not install the NCL appliance itself. It automates initial bootstrap and organization setup, then supports ongoing configuration and day-2 operations after an NCL endpoint is reachable.
Why this release matters
NCL is often deployed where security, data sovereignty, or connectivity requirements call for local control. Those same environments commonly have strict change-management processes and limited tolerance for configuration drift. Ansible provides a practical operating model for both needs.
Agentless operation. The modules run from an Ansible control node or execution environment and communicate with NCL over HTTPS. There is no agent to deploy on NCL or on each managed ONTAP system.
Idempotent outcomes. Modules follow Ansible's state model. A state of present creates or updates only when necessary, absent removes a resource only when it exists, and query reads current state without making changes. Re-running a playbook is therefore predictable and safer than replaying imperative scripts.
Consistency at scale. The same reviewed playbook can be applied across development, test, production, remote sites, or multiple organizations. Site-specific values live in variable files or credentials rather than being embedded in automation logic.
Auditability and repeatability. YAML playbooks can be stored in source control, peer reviewed, linked to change records, and executed through CI/CD or Red Hat Ansible Automation Platform (AAP). The playbook becomes both an executable procedure and documentation of the desired state.
Lower operational risk. Standard modules replace hand-built API calls, while check mode, validation, Ansible Vault, and reusable templates provide guardrails for repeatable changes.
Faster time to value. Teams can start with NetApp-supplied examples for common workflows instead of designing authentication, organization discovery, payload handling, and error processing from scratch.
What is included in netapp.console 1.0.0
The collection covers the Console local deployment lifecycle from initial setup through system onboarding, governance, identity, notifications, policy management, and storage provisioning. The live Ansible Galaxy metadata lists 26 modules in version 1.0.0.
Capability area | Modules | Operational value |
|---|
Bootstrap and identity | local_bootstrap, local_organization_setup, local_user_registration, org_users, service_accounts, generate_oauth_token | Establish the initial organization, users, roles, service identities, and authentication. |
Systems and hierarchy | add_new_systems, deregister_system, query_working_environments, storage_fleets, add_systems_to_fleet, remove_system_from_fleet, folder_management, scope_management, local_agent_info | Register ONTAP systems and organize them into fleets, folders, and scopes. |
Policy and governance | capacity_policies, performance_policies, protection_policies, security_policies, storage_classes | Express capacity, performance, protection, security, and service-level intent as code. |
Storage operations | storage_provisioning, ontap_volumes_management | Provision volumes or LUNs and query or remove ONTAP volumes through NCL. |
Platform integrations | active_directory, email_config, webhooks, llm_config | Configure identity federation, email, webhooks, and supported LLM integrations. |
How the collection works
Every module uses the fully qualified collection name netapp.console.<module_name>. Most modules accept a common set of connection parameters: the NCL console URL, an OAuth2 access token, an organization ID, certificate-validation behavior, and an HTTP timeout.
NetApp's example playbooks follow a consistent flow: authenticate unless an access token is already supplied, discover the organization when an organization ID is not set, and then execute the requested action. Modules run locally on the Ansible control node and call the NCL REST APIs directly.
This design is especially useful for disconnected or restricted environments. The control node only needs network reachability to the NCL appliance. For fully air-gapped sites, download the collection artifact and any playbook content in a connected staging environment, transfer them through the organization's approved process, and install them locally.
Configure the collection in your environment
1. Prepare an Ansible control node
Use a Linux host, automation runner, or supported execution environment with network access to the NCL HTTPS endpoint. The PACE documentation calls for Python 3.11 or later and ansible-core 2.15 or later. For production, use Python linked to a current OpenSSL implementation and ensure the NCL certificate authority is trusted.
2. Install Ansible and verify the version
Create a Python virtual environment to avoid changing system packages, install Ansible, and verify that the runtime meets the collection requirement.
python3 -m venv .venv
source .venv/bin/activate
python -m pip install 'ansible-core>=2.15'
ansible --version
3. Install the collection from Ansible Galaxy
Install the latest published netapp.console collection. Pin version 1.0.0 in controlled environments so development, CI, and production use the same artifact.
# Install the published collection
ansible-galaxy collection install netapp.console:1.0.0
# Confirm the installed collection
ansible-galaxy collection list netapp.console
4. Get the NetApp example playbooks
The modules are distributed through Galaxy; the runnable playbooks and variable templates are maintained in the public NetApp PACE repository.
git clone https://github.com/NetApp/pace.git
cd pace/ansible/console/local
5. Configure the NCL connection
Copy vars/ncl.yml to an environment-specific file and provide the NCL URL and authentication details. Include the https:// scheme. You may leave ncl_org_id empty when the playbook supports automatic organization discovery.
cp vars/ncl.yml vars/my_ncl.yml
# Edit vars/my_ncl.yml
ncl_console_url: "https://ncl.example.com"
ncl_admin_email: "ncl-admin@example.com"
ncl_admin_password: "CHANGE_ME"
ncl_org_id: ""
ncl_access_token: ""
ncl_validate_certs: true
ncl_timeout: 60
6. Protect credentials
Do not commit passwords, API keys, or access tokens to source control. Encrypt the variable file with Ansible Vault, inject secrets from AAP credentials, or supply short-lived values through an approved secrets manager. Environment variables such as NCL_CONSOLE_URL, NCL_ACCESS_TOKEN, NCL_ORG_ID, and NCL_VALIDATE_CERTS are supported shortcuts for automation pipelines.
ansible-vault encrypt vars/my_ncl.yml
# Run later with the Vault password
ansible-playbook playbooks/site.yml \
--extra-vars '@vars/my_ncl.yml' \
--ask-vault-pass
7. Verify installation and module documentation
Confirm that Ansible can resolve the collection and inspect each module's supported parameters and states before building a production playbook.
ansible-doc netapp.console.storage_provisioning
ansible-doc netapp.console.active_directory
ansible-doc netapp.console.storage_fleets
8. Run the bootstrap or a targeted workflow
Use site.yml for the initial user and fleet workflow, or run an individual playbook for a specific operation. Start in a non-production environment, review output, and use check mode where the selected module supports it.
# Initial setup: user registration and fleet management
ansible-playbook playbooks/site.yml \
--extra-vars '@vars/my_ncl.yml' \
--ask-vault-pass
# Example: provision storage
ansible-playbook playbooks/storage_provisioning.yml \
--extra-vars '@vars/my_ncl.yml' \
--extra-vars '@vars/ncl_storage_provisioning.yml' \
--ask-vault-pass
Pin the collection for repeatable automation
For CI/CD, AAP, or AWX projects, add a correctly indented requirements.yml to the project root:
---
collections:
- name: netapp.console
version: '1.0.0'
Install all declared collections with:
ansible-galaxy collection install -r requirements.yml
Build your own NCL playbook
After installation, you can use the modules from any Ansible project. Run NCL tasks on localhost, authenticate first, register the returned token, and pass that token to subsequent tasks. The following is a minimal pattern; confirm parameter names against ansible-doc for the installed version before use:
---
- name: Manage NCL storage as code
hosts: localhost
connection: local
gather_facts: false
vars_files:
- vars/my_ncl.yml
tasks:
- name: Authenticate to NetApp Console Local
netapp.console.generate_oauth_token:
console_url: "{{ ncl_console_url }}"
username: "{{ ncl_admin_email }}"
password: "{{ ncl_admin_password }}"
validate_certs: "{{ ncl_validate_certs }}"
register: auth
no_log: true
- name: Ensure the application volume exists
netapp.console.storage_provisioning:
console_url: "{{ ncl_console_url }}"
access_token: "{{ auth.access_token }}"
org_id: "{{ ncl_org_id }}"
state: present
volume_name: app_data_01
size_gb: 100
protocol: nfs
validate_certs: "{{ ncl_validate_certs }}"
Production recommendations
- Validate TLS certificates in production. The examples default ncl_validate_certs to false for convenience, but production automation should trust the issuing CA and set it to true.
- Pin collection versions in requirements.yml and promote changes through test and production using the same reviewed artifact.
- Use dedicated service accounts and least-privilege roles instead of personal administrator credentials for recurring jobs.
- Mark authentication tasks no_log: true and review job output to ensure tokens and passwords cannot appear in logs.
- Test destructive actions carefully. Confirm the semantics of state: absent and any force or cascade option in ansible-doc before enabling scheduled execution.
- Use source control, pull requests, linting, and change approvals for playbooks and non-secret variable files.
- For AAP or AWX, point a Project at the PACE repository or an approved fork, add netapp.console to requirements.yml, inject secrets through credentials, and expose safe inputs through surveys or extra variables. No managed-host inventory or SSH credential is required because the modules execute on localhost.
The value for infrastructure and storage teams
For storage administrators: repeatable workflows reduce UI-driven effort and provide a supported starting point for onboarding systems, managing fleets, applying policies, and provisioning storage.
For platform engineering teams: NCL can participate in GitOps, CI/CD, service catalogs, and AAP workflows alongside other infrastructure components.
For security and governance teams: reviewable playbooks, encrypted secrets, dedicated service accounts, and consistent policy application improve control and traceability.
For the business: faster provisioning, fewer manual errors, and reusable automation shorten delivery cycles while preserving local control of data-management operations.
Call to action: automate your first NCL workflow
The netapp.console collection is available now. A practical way to begin is to select one low-risk, high-frequency workflow and take it from manual execution to a reviewed playbook:
- Install netapp.console from Ansible Galaxy and explore the module documentation.
- Clone the NetApp PACE repository to obtain tested playbook examples and variable templates.
- Choose one repeatable NCL workflow—such as onboarding an ONTAP system, creating a fleet, assigning users, or provisioning a volume—and validate it in a non-production environment.
- Share feedback and report issues through the NetApp PACE GitHub repository so the collection can continue to evolve around real operational use cases.
Get started today: install netapp.console from Ansible Galaxy, then download the example playbooks from NetApp PACE.
Links to other NetApp Console local deployment blogs:
