Skip to content

Usage Examples

Ready-to-use Terraform configurations for every feature of the Qumulo provider.

First time here?

Install and verify the provider, then set up credentials in the provider configuration reference. Already running a cluster that Terraform does not know about? Every resource supports terraform import; start with the import guide.

Deploy a cluster

The three cloud filesystem resources share the same naming, deletion-protection, and boot-customization options:

Manage a cluster

These examples work against any Qumulo cluster (cloud, on-prem, or edge) through a connection profile; no cloud credentials required. Profiles are defined once in the provider block; see the provider configuration reference. Fleet management shows how to drive many clusters from one configuration with for_each.

Storage protocols and data access

Example Description
NFS Exports NFS exports with host restrictions and identity mapping
SMB Shares SMB shares with trustee and network permissions
SMB Settings SMB server settings (signing, encryption)
FTP Settings FTP server configuration
S3 S3 buckets, policies, and access keys

Identity and access

Example Description
Active Directory AD domain join and protocol settings
LDAP Settings LDAP authentication configuration
SAML Settings SAML SSO with external identity providers
Local Users Local users, groups, and group membership
Roles RBAC roles and role assignments

Data management and protection

Example Description
Directory Quotas Per-directory capacity limits
Snapshot Policies Automated point-in-time backups
Replication Cluster-to-cluster and object storage replication
Portal Cloud Data Fabric hub/spoke portals
Audit Logging Syslog and CloudWatch audit log shipping

Cluster administration

Example Description
Cluster Settings Cluster name, SSL/TLS, and time configuration
File System Settings Permissions mode, atime, notifications
Web UI Settings Session timeout and login banner
Fleet Management Multi-cluster management with for_each

Store your state

Example Description
S3 Store Terraform state in S3
Azure Blob Store Terraform state in Azure Blob Storage
GCS Store Terraform state in Google Cloud Storage

Protecting a cluster from deletion

This applies to qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp alike. The AWS resource is shown; swap the resource type for your cloud.

Set deletion_protection = true to guard the cluster's nodes and backing storage against deletion, including terraform destroy and, where the cloud supports it, the console and CLI:

resource "qumulo_filesystem_aws" "prod" {
  # ... other required fields ...
  deletion_protection = true

  timeouts {
    create = "90m"
    delete = "30m"
  }
}

Deleting a protected cluster is a deliberate two-step gesture:

# 1. Set deletion_protection = false in your config, then apply it
#    (running destroy without this apply still refuses):
terraform apply

# 2. Now destroy proceeds:
terraform destroy

Provider-managed operations (scaling, node replacement, configuration updates) succeed transparently while protection is on. The provider reconciles the real cloud protection state on every refresh, so out-of-band tampering (someone clearing a flag in the console) shows up as a plan diff and the next apply re-asserts protection everywhere.

Azure requires lock permissions

On Azure, protection is implemented with CanNotDelete management locks on every cluster VM and storage account. Managing locks requires the Microsoft.Authorization/locks/* permission (Owner, User Access Administrator, or a custom role); Contributor alone is not enough, and the provider checks this at plan time when deletion_protection = true.

GCP buckets are gated by Terraform only

GCS has no bucket deletion-protection mechanism, so on GCP the cloud-side flags cover the node instances only. The cluster's GCS buckets are covered by the terraform destroy gate alone; console and CLI bucket deletion is not blocked, unlike AWS and Azure. See deletion protection on GCP.

Riding out cloud capacity shortages

Cloud regions occasionally run out of capacity for a specific instance type in a specific zone, especially for large types packed into a single availability zone. When this happens during cluster creation, scale-up, or node replacement, the provider now retries each node launch with backoff for up to 60 minutes before giving up, so a brief crunch (which usually clears in seconds to a couple of minutes) no longer fails your apply. Retries apply to qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp. Set TF_LOG=WARN to watch the retry progress; Terraform's "Still creating..." line keeps ticking while the provider waits.

Only genuine capacity/allocation-exhaustion errors are retried (AWS InsufficientInstanceCapacity, Azure AllocationFailed / ZonalAllocationFailed, GCP ZONE_RESOURCE_POOL_EXHAUSTED). Quota errors, unavailable-SKU / unsupported instance types, and configuration errors fail fast, since waiting cannot fix them.

Sustained shortages take longer to surface

Because the retry window is 60 minutes, a sustained shortage now fails after up to ~60 minutes instead of ~1 minute. If you run applies under a tight CI timeout, size the Terraform create timeout accordingly (the retry never exceeds it — the provider reserves a margin so the normal rollback still runs).

For a shortage that does not clear, the durable fixes are:

  • Reserve capacity in the target zone. On AWS, an On-Demand Capacity Reservation (ODCR) or Capacity Block for the instance type guarantees the nodes can launch. Azure and GCP offer equivalent reservations.
  • Spread across availability zones. A multi-AZ cluster does not use a cluster placement group, so it is far less likely to hit a single-zone capacity wall.
  • Choose a different instance type that is available in the target zone.

Serving cluster DNS with cluster_fqdn

Set cluster_fqdn on qumulo_filesystem_{aws,azure,gcp} to have Qumulo Core act as the authoritative DNS server for that name, round-robining across the cluster's floating IPs. It requires at least one floating IP and cluster_version 7.5.0 or newer.

DNS delegation is your responsibility

The provider only configures the cluster to answer for cluster_fqdn. You must delegate or forward that name to the cluster's floating IPs in your own DNS (for example, an NS delegation or a conditional forwarder pointing at the floating IPs). The provider does not create any cloud DNS records or resolver rules.