From 10 modules to full-cluster automation: what’s new in v2.x, and what each release added

Why this matters

Most of the VAST clusters I talk to customers about don’t live alone. There’s a production cluster, a DR cluster, often a dev cluster, and increasingly a mix of VAST 5.4 and 5.5 running at the same time. Managing views, tenants, identity providers and protection policies by clicking through VMS works fine for one cluster. For five, with change control and audits, it doesn’t.

That’s the gap the VAST Ansible collection, vastdata.vms, fills. It’s open source (Apache-2.0), published on Ansible Galaxy, and it has grown from a 10-module starter kit into a collection that covers most of what you’d do in VMS: data services, identity, data protection, tenancy, observability and the security settings of VMS itself.

Figure 1: One collection, many clusters. Playbooks declare desired state; vastdata.vms adapts to each cluster’s VMS version.

What you get with every module

• Idempotency: run the same playbook ten times, change the cluster once.
• Check mode (–check) and diff mode (–diff): preview exactly what will change before it changes.
• Read-only *_info modules: discover and look up resources without touching them.
• clear_fields: explicitly reset optional fields to empty/null where supported.
• Ansible Vault support and clear, actionable error messages.
• Token auth (VAST 5.3+) or username/password.

Getting started

ansible-galaxy collection install vastdata.vms

# or pin a version

ansible-galaxy collection install vastdata.vms:==2.2.0

Requirements: Python 3.9+, ansible-core 2.15+, and the requests library. Supported VAST software: 5.4.x and 5.5.x, and one install auto-adapts to each cluster’s VMS version, so a mixed-version fleet can be driven from the same controller.

Since 2.0.0, every module belongs to the vastdata.vms.all action group, so you declare the connection once per play:

– hosts: localhost

  module_defaults:

    group/vastdata.vms.all:

      vms:

        host: vast-vms.example.com

        token: “{{ vast_token }}”

  tasks:

    – name: Create a tenant

      vastdata.vms.tenants:

        name: research

        state: present

    – name: Create a view for it

      vastdata.vms.views:

        path: /research/datasets

        state: present

    – name: Inventory VIP pools

      vastdata.vms.vippools_info:

What each release added

Here’s what each version of the collection added, taken from the project’s changelog:

Version	Theme	What it added
1.0.0	Foundations	dns, groups, ldaps, quotas, s3policies, tenants, users, viewpolicies, views, vippools (token auth on VAST 5.3+ or username/password; idempotency, check and diff mode)
1.1.0	Identity + REST client	eventdefinitionconfigs, nonlocal_group, nonlocal_user; vastpy SDK replaced by a self-contained REST client (VastClient); debug tracing, central timeouts, version in User-Agent
1.2.0	Data protection	globalsnapstreams, nativereplicationremotetargets, protectedpaths, protectionpolicies, snapshots, user_key
1.3.0	IAM, access, QoS	activedirectory, administrator_role, apitokens, apitoken_revoke, iamroles, iam_role_credentials, iamrole_revoke_access_keys, localproviders, managers, manager_password, manager_authorized_status, qospolicies, realms, s3lifecyclerules
1.3.1	Orchestration	protectedpath_streams module + the vastdata.vms.protectedpath role (VIP pools, replication peers, protection policies, protected paths, replication/standby streams)
2.0.0	Platform release	Read-only *_info modules for every listable resource; one collection for VMS 5.4 + 5.5; module_defaults group vastdata.vms.all; ansible-core >= 2.15; Apache-2.0; callhomeconfigs, callhomeconfig_register_cluster, callhomeconfig_send, vms, vms_configured_idps, vms_set_max_api_tokens, nonlocal_user_key, nis, nis_set_posix_primary
2.1.0	Auth + events	oidcs, userquotas, webhooks, kerberos, kerberos_keytab (+ matching *_info), challengetokens_info, permissions_info, nonlocal_user_info, nonlocal_group_info; *_info for every remaining listable resource
2.2.0	Security + ops	tlscertificates (+ _info, _is_operation_healthy, _crl); vms_set_certificate, vms_reset_certificate, vms_set_client_certificate, vms_remove_client_certificate, vms_set_ssl_ciphers, vms_reset_ssl_ciphers, vms_set_ssl_port, vms_toggle_maintenance_mode, vms_login_banner, vms_pwd_settings, vms_saml_config (+ _info); vms_network_settings, vms_network_settings_info, vms_network_settings_summary; topic_show, topic_delete, schema_show, schema_delete, table_show, table_delete; quotagroups + assign/refresh/reset actions; tenant_metric_labels / label_values / _bulk; health_info, issues_info, issue_pre_install_validations; supportbundlesqueue_info, encryptiongroups_info; blobexpansions family (VMS 5.5+); richer *_info filters aligned with the API

Figure 2: vastdata.vms release timeline, 1.0.0 to 2.2.0.

Highlights of the 2.x line

2.0.0: from modules to a platform

2.0.0 is the release that changed how the collection gets built and used. It added read-only *_info modules, generated a single collection that targets both VMS 5.4 and 5.5, introduced the vastdata.vms.all group, relaxed the Ansible requirement to ansible-core 2.15+, and relicensed everything under Apache-2.0 as part of Red Hat certification hardening. Under the hood, the REST client now raises typed errors (VastNotFoundError, VastAPIError) instead of matching strings.

2.1.0: identity and events

OIDC, Kerberos (including keytab generation), per-user quotas and webhooks all landed, along with *_info coverage for every remaining listable resource. If you’re wiring VAST into an enterprise IdP or an event-driven workflow, this is the release that makes it possible end to end.

2.2.0: VMS security and day-2 operations

The latest release covers the settings security teams care about: TLS certificate lifecycle and CRLs, installing and resetting VMS certificates, mTLS client certificates (with a VAST_CLIENT_CERT / VAST_CLIENT_KEY recovery path), SSL ciphers and port, SAML configuration, network settings (with a summary module that previews changes before applying them), login banners and password policy. It also adds quota groups, tenant metric labels for chargeback and showback, health and issue reporting, pre-install validations, and the blobexpansions family for VAST DataBase on VMS 5.5+, and topic, schema and table helpers (show/delete). The *_info modules also gained richer filters that match what the API actually accepts.

Before you upgrade to 2.2.0, check for breaking changes. saml_config / saml_config_info are gone (use vms_saml_config), topics no longer supports state: absent (use topic_delete), and a few *_info filter arguments were renamed to match the API (for example, nonlocal_user_info now filters by username).

Figure 3: Automation coverage by domain in v2.2.0 (representative modules).

Beyond single modules: the protectedpath role

Since 1.3.1, the collection ships a role, vastdata.vms.protectedpath, that orchestrates a complete protected-path setup: VIP pools, replication peers, protection policies, the protected path itself and its replication/standby streams. Setting up DR used to take a checklist and a careful hour in the UI. Now it’s one version-controlled play you can re-run.

Wrap-up

If you run VAST at scale, treating the cluster as code is now practical: a single collection, both current VMS versions, check and diff before every change, and coverage from views all the way to TLS. Install it from Galaxy, point it at a lab cluster, and start with the *_info modules to inventory what you already have.

Repo: github.com/vast-data/vast-ansible  ·  Galaxy: galaxy.ansible.com/ui/repo/published/vastdata/vms/

Related on Lots of Data: VAST AI OS API Documentation Hub · The Thing That Enables the THING · K8s DR with VAST CSI 5.5