Changelog

All notable customer-facing changes to the Qumulo Terraform Provider are documented in this file.

The format is based on Keep a Changelog.

1.4.13 - 2026-09-03

Added

• qumulo_filesystem_azure: private endpoints no longer require an Azure Private DNS zone. create_appconfig_private_endpoint, create_keyvault_private_endpoint, and create_storage_private_endpoint each build an endpoint in the cluster subnet on their own, and the new computed outputs appconfig_private_endpoint, keyvault_private_endpoint, and storage_private_endpoints report each endpoint's FQDN, private IP, endpoint name, resource group, and the ARM ID of the resource it fronts, so operators who run their own DNS (Infoblox, BlueCat, on-prem BIND) can create the records from Terraform outputs and later PATCH that resource's network ACLs themselves. Public network access must stay enabled while the cluster is created in that case, because the endpoint address does not exist until the apply creates it. See "Private Endpoints" in the Azure production guide for the full sequence.
• qumulo_filesystem_azure: storage accounts can now have private endpoints at all. create_storage_private_endpoint creates one blob endpoint per account, and a soft_capacity_limit_tb increase that adds accounts gives each new account its own endpoint. private_link_storage_dns_zone_id registers them in a privatelink.blob.core.windows.net zone. Each endpoint carries a per-hour Azure cost.
• qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp: after a provisioner run the provider logs the exact command that tails that run's provisioner logs (CloudWatch, Log Analytics, or Cloud Logging).

Changed

• qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp: the provisioner boot process is now a single script on all three clouds.
• qumulo_filesystem_azure: the provisioner no longer probes google.com after boot. The probe only wrote an informational status and AWS and GCP provisioners never had it.
• qumulo_filesystem_azure: private_link_appconfig_dns_zone_id and private_link_keyvault_dns_zone_id no longer create the private endpoint on their own. They now only register an endpoint that create_appconfig_private_endpoint, create_keyvault_private_endpoint, or create_storage_private_endpoint asked for, so a configuration that sets only a zone ID now fails validation. The fix is one line: add create_appconfig_private_endpoint = true or create_keyvault_private_endpoint = true beside the zone ID.
• qumulo_filesystem_azure: a private endpoint the configuration asked for and the provider could not create now fails the apply. It previously logged a warning and continued, which left a cluster whose public network access was disabled unreachable with no error to explain why.
• qumulo_filesystem_aws: a nonzero floating_ip_count on a multi-AZ deployment is now accepted with a warning instead of rejected. Floating IPs are not applied while more than one zone is in use, and the count takes effect again when the cluster returns to a single zone.

Fixed

• provisioner_hooks.pre_run now runs before the provisioner's first network operation (logging agent install, tooling installs, cloud CLI auth, storage-access validation) on all three clouds. Previously the provisioner installed tooling over the network before pre_run ran, so a hook meant to configure a proxy, corporate CA, or air-gapped mirror ran too late to affect that tooling install, breaking proxy-only environments.
• qumulo_filesystem_azure: on clusters using persistent_storage_resource_group (imported azure-terraform-cnq deployments), the Key Vault private endpoint is now created with the same name and in the same resource group that the destroy path looks in. Create used the cluster resource group and deployment name, and destroy used the storage ones instead, so the endpoint survived a terraform destroy and kept accruing charges.
• qumulo_filesystem_aws: the deletion protection read now reports an error when it finds no cluster nodes or no buckets instead of treating the cluster as unprotected.

1.4.12 - 2026-08-25

Fixed

• qumulo_filesystem_aws: changing deletion_protection on an existing cluster now takes effect. The update looked the cluster's EC2 instances and S3 buckets up by a name derived from the configuration, which lacks the unique suffix minted when the cluster was created, so it matched no resources and the toggle silently did nothing. Refresh reads the live setting correctly, so the change came back in every following plan and never converged — and a cluster the plan reported as protected was not actually protected. Creating a cluster is unaffected: protection is applied as each instance and bucket is created.

1.4.11 - 2026-08-21

Changed

• deployment_name on qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp now accepts uppercase letters, matching what name and cluster_name already allowed and what the legacy Qumulo providers accept. A cluster deployed with capitals in its deployment name could not be managed after import: the value failed validation on every plan. Derived cloud resource names are still lowercased, because S3 and GCS buckets, GCE names, and Azure storage accounts require it, so case is cosmetic — changing only the case of an existing deployment_name renames nothing and does not replace the cluster. Changing it to a different name still forces replacement.

Fixed

• qumulo_filesystem_aws: lowering floating_ip_count in the same apply as a node replacement no longer fails. Excess addresses were released using the node network interfaces recorded at plan time, which the replacement had already deleted along with the old nodes, so the release errored out after the new nodes were up. The provider now discovers the cluster's live interfaces at the moment it releases the addresses.
• qumulo_filesystem_aws: a failure partway through an update no longer records the pre-update node count and instance type over a cluster that has already scaled or been replaced. The compute change is now checkpointed as soon as the provisioner run succeeds, and the floating-IP set separately once the addresses have actually left the interfaces, so a retry after a mid-update failure sees the cluster as it is instead of replanning work that already landed.

1.4.10 - 2026-08-18

Fixed

• qumulo_filesystem_azure: updates that reapply floating IPs on a host_managed cluster (a scale, node replacement, or any update after a floating-IP change) no longer write the cluster network with a 0.0.0.0 netmask. The update-path provisioner run was missing the subnet CIDR, so the calculated netmask collapsed to zero and Qumulo Core rejected the network write (versions 1.4.6 through 1.4.9 are affected). The provider now resolves the subnet's address prefix for every update, and the provisioner refuses to write a netmask it cannot derive instead of writing a corrupt one. As part of the same fix, floating-IP comparison now canonicalizes Qumulo Core's coalesced range form (10.0.1.2-4) against the configured individual addresses, so unchanged floating IPs are no longer re-applied on every update pass.

1.4.9 - 2026-08-14

Changed

• qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp no longer guess an imported cluster's networking_mode. No API the provider can reach reports whether Qumulo Core or the cloud owns a cluster's floating IPs, so import now leaves the attribute unset instead of recording host_managed. A plan that would add, resize, or clear floating IPs on such a cluster fails with networking_mode is required to manage floating IPs; set networking_mode to match how the cluster was actually deployed and plan again. Plans that leave the floating-IP count at zero are unaffected, as are clusters the provider created: they keep the mode they were deployed with, and host_managed remains the default for a new cluster that does not declare one. Previously the assumed value could strip the live floating IPs off a qumulo_managed cluster, or silently do nothing at all.

Fixed

• qumulo_filesystem_azure: creating a larger cluster no longer fails with an Azure customData length error. The provisioner script had grown past Azure's limit of 87380 base64 characters, so cluster creation failed before any node booted. Boot payloads are now compressed before encoding (cloud-init inflates them transparently), which takes a script that had reached roughly 67 KB down to about 24 KB encoded. Six-node clusters that register with Qumulo Nexus were the first to cross the limit, since registration adds around 2 KB to the script. Cluster node and threat detection boot payloads on Azure go through the same encoder and gain the same headroom.
• qumulo_filesystem_azure now rejects storage_class = "INTELLIGENT_TIERING" with storage_replication_type = "LRS" at plan time. Azure only permits the Smart access tier on zone-redundant storage, so this combination previously failed partway through apply with a raw Azure InvalidRequestPropertyValue response, after the resource group and network were already built. Because storage_class defaults to INTELLIGENT_TIERING on Qumulo Core 7.8.4 and newer, any cluster that explicitly set storage_replication_type = "LRS" hit this. Set storage_replication_type = "ZRS" to keep intelligent tiering, or storage_class = "STANDARD" for plain hot storage. Both attributes are immutable after creation. Clusters using the default storage_replication_type (ZRS) were never affected.

1.4.8 - 2026-08-10

No functional changes. This release rebuilds the provider with an updated release pipeline; behavior is identical to 1.4.7.

1.4.7 - 2026-08-10

Added

• qumulo_filesystem_aws gains an optional floating_ip_count_ipv6 attribute (default 0) requesting an IPv6 floating IP pool, alongside the existing floating_ip_count for the IPv4 pool. Like floating_ip_count, it must be 0 or between 3 and 100.
• With a non-zero floating_ip_count_ipv6, the cluster's floating endpoints are IPv6 addresses on the node ENIs: launches allocate them atomically, the security group mirrors every cluster ingress rule for your IPv6 allow CIDRs (defaulting to the VPC's IPv6 CIDR when allow_cidrs has no IPv6 entries) and adds an ::/0 egress rule, and floating_ips, endpoint_ips, and cluster_reference carry the IPv6 addresses.
• Requires cluster_version 7.9.2.1 or later (set explicitly) and an IPv6-enabled (dualstack) subnet; nodes keep IPv4 primary addresses for internode and management traffic. Core builds before 7.9.2.1 accept IPv6 floating ranges in network config, but their AWS floating-IP mover only handles IPv4, so v6 floats never fail over between nodes.
• floating_ip_count and floating_ip_count_ipv6 cannot both be non-zero: Qumulo Core does not yet support simultaneous IPv4 and IPv6 floating IPs on AWS. Set one and leave the other at 0.
• A cluster's floating pool cannot be migrated from one address family to the other in place — swapping would drop every client connected to the current pool — so the plan fails with an actionable error. Resizing the pool the cluster already has (including clearing it to 0) is supported, and a cluster with no floating IPs can enable either family.
• On import, declare floating_ip_count_ipv6 = <pool size> for a cluster whose floating IPs are IPv6, exactly as you would declare floating_ip_count for an IPv4 cluster. The provider reads the live addresses back into floating_ips either way.
• allow_cidrs accepts IPv6 CIDR entries only when floating_ip_count_ipv6 is non-zero.
• The node IAM role's inline policy now also grants ec2:AssignIpv6Addresses, ec2:UnassignIpv6Addresses, and ec2:DescribeNetworkInterfaces (see the Bring Your Own IAM guide for the updated policy).
• Existing IPv4 deployments are unaffected. qumulo_threat_detection_aws does not yet support IPv6 cluster endpoints and rejects them with a clear error.

Changed

• qumulo_filesystem_aws: security group reconciliation now recognizes IPv6 rules. A manually added IPv6 rule on a provider-managed security group is removed on the next update, matching existing IPv4 behavior (previously such rules were invisible to reconciliation).
• New qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp clusters now require Qumulo Core 7.9.2 or newer, enforced at plan time. Existing clusters running older versions are unaffected: import and update continue to work. Replacing an existing cluster re-creates it at its existing cluster_version, so replacement of a cluster already below the floor is not blocked.

Fixed

• qumulo_filesystem_aws: clusters whose instance type supports AWS ENA Express (e.g. i7ie, i7i 12xlarge+, i4i 8xlarge+, m6idn 8xlarge+) now get ENA Express enabled automatically on every node's network interface, raising single-flow bandwidth from 5 Gbps up to 25 Gbps (a single NFS/SMB mount or replication stream). Existing clusters are enabled retroactively on their next update, and replaced or added nodes are re-enabled automatically. No configuration is required and no new permission is needed: the deploying credentials already require ec2:ModifyNetworkInterfaceAttribute. Fixes the unreachable/broken ENA Express step in the embedded provisioner script (#748).

1.4.6 - 2026-07-31

BREAKING

• floating_ips on qumulo_filesystem_gcp and qumulo_filesystem_azure is now a read-only output and can no longer be set in configuration. floating_ip_count is the only way to ask for floating IPs, as on qumulo_filesystem_aws. A configuration that still sets the attribute fails immediately with Error: Value for unconfigurable attribute — Can't configure a value for "floating_ips". To migrate: delete the floating_ips = [...] line and set floating_ip_count to the number of addresses it listed. The cluster keeps the exact addresses it already has — the provider reads them back into floating_ips as an output on the next refresh — so there is no address change, no cluster change, and no state migration. Note the omitted-attribute behavior differs from AWS: on Azure and GCP, omitting floating_ip_count after a count has been applied keeps the previously applied count, while on AWS omitting it means 0. On GCP this retires the deprecation announced in 1.4.5, where supplying the list was the documented migration path; the list-to-count swap described there is still the correct fix, it is now required rather than recommended.

Changed

• qumulo_filesystem_aws: the deploying credentials now need ec2:ModifyInstanceAttribute and s3:GetBucketPolicy for every cluster, not just those using deletion_protection. Deletion protection is now applied when a node instance or bucket is created rather than in a pass after the cluster is up, and lifted immediately before that resource is terminated or deleted. Because the lift runs unconditionally, a scale-down, node replacement, or terraform destroy on credentials scoped without these two actions will now fail with an access-denied error where it previously succeeded. Add both to the deploying policy before upgrading; the Bring Your Own IAM policy already grants them. ec2:DescribeInstanceAttribute remains needed only when you use deletion_protection, and only to report live protection state on refresh. One behavior improves as a side effect: a create can no longer report success with protection partially applied, so the "cluster was created successfully, but deletion protection could not be applied" warning is gone.

• qumulo_filesystem_azure and qumulo_filesystem_gcp: every refresh now reads the cluster's live floating IPs from the node NICs (Azure) or alias IP ranges (GCP), never node primary IPs, so out-of-band changes surface as drift, and endpoint_ips derives from the live floats instead of the configured list. A genuine floating-IP change updates endpoint_ips and cluster_reference and can trigger a one-time replacement of downstream qumulo_threat_detection_azure / qumulo_threat_detection_gcp resources, matching the existing AWS behavior; no-op refreshes do not churn.

Fixed

• qumulo_filesystem_azure: changing floating_ip_count on an existing cluster actually applies the change now. The update-path provisioner run omitted the maximum-floating-IP count, so the script clamped the requested list to empty and silently skipped the cluster network update. A new reconcile_floating_ips guard also lets the count be cleared to zero, which previously could never complete. The provider now waits (up to 10 minutes) for the node NICs to converge on the requested addresses before recording state.
• qumulo_filesystem_gcp: after a floating_ip_count change, the provider now waits (up to 10 minutes) for the new alias addresses to attach to the node NICs before reading state, eliminating a race where an empty read was recorded and then carried forward on subsequent plans.
• qumulo_filesystem_aws: imported qumulo_managed clusters with live floating IPs now derive endpoint_ips from those floats instead of falling back to node primary IPs (floating_ip_count being unset no longer suppresses float-based endpoints). This updates cluster_reference and can trigger a one-time replacement of a downstream qumulo_threat_detection_aws appliance on the first refresh after upgrading.

1.4.5 - 2026-07-28

Added

• qumulo_filesystem_aws gains an optional audit_logging attribute (default false) that turns CloudWatch audit logging on or off for the cluster, plus an optional, computed audit_log_group_name attribute (defaults to /qumulo/<deployment_unique_name>-audit-log) naming the destination log group. The provider creates the log group only when it is missing and never deletes it, so audit history survives terraform destroy; it never touches an existing group's retention, encryption, or tags. The provider automatically targets Qumulo Core's V1 CloudWatch audit config API below version 7.9.0 and the V2 named-destination API at 7.9.0 and above, based on the running cluster version (V2 support has unit and render-test coverage only; no 7.9.0+ build exists in the package registry yet to verify against a live cluster). While audit_logging is true the provider reasserts the configuration on every provisioner run, so a scaled or replaced cluster keeps its audit destination; changing the attribute to false disables auditing on the cluster. Leaving it at its default false does not touch audit configuration made outside Terraform, such as with qq or the qumulo_audit_cloudwatch resource. The deploying credentials need three additional permissions -- logs:DescribeLogGroups, logs:CreateLogGroup, and logs:TagResource -- deliberately excluding logs:DeleteLogGroup; see the production and Bring Your Own IAM guides for the updated permission lists.

• qumulo_filesystem_gcp gains an optional floating_ip_count attribute, replacing the deprecated floating_ips list as the way to give the cluster floating IPs. Set a count (0 to disable, or between 3 and 100; the cluster needs at least 2 nodes) and the provider reserves that many internal static addresses from the cluster subnet and manages them for the cluster's lifetime: changing the count reallocates in place (existing addresses are kept when growing so they don't churn; excess reservations are released when shrinking, in one provisioner run merged with any concurrent scale, replacement, or cluster_fqdn change), and setting 0 or destroying the cluster releases every provider-owned reservation. Requires the host_managed networking mode; under the qumulo_managed networking mode Qumulo Core owns the floating IPs and the count stays 0. The count resolves to 0 on create and on the first plan after import when unset; once a count has been applied, omitting the attribute keeps the previous value, so set it to 0 explicitly to remove floating IPs.

• qumulo_threat_detection_aws instance_type, qumulo_threat_detection_azure vm_type, and qumulo_threat_detection_gcp machine_type can now be changed in place. Previously any size change forced the appliance to be destroyed and recreated; now the provider stops the VM, changes its size, and restarts it, preserving the boot disk, data, and the Elastio installation. Threat detection scanning is unavailable for roughly 5-10 minutes during the resize, and terraform plan warns about the outage. Changing to a different CPU architecture (x86_64 ↔ arm64) is rejected before the VM is touched, since the boot image cannot follow; use terraform apply -replace for that. If a resize fails, the provider restarts the VM at its original size; if even that restart fails, the error names the size the VM is stopped at; keep the new size in your configuration and re-run apply to retry starting it. deletion_protection = true does not block a resize (nothing is deleted). The deploying credentials need additional permissions to stop, resize, and start the appliance VM: on AWS ec2:StopInstances, ec2:StartInstances, ec2:ModifyInstanceAttribute, and ec2:DescribeInstanceTypes; on Azure Microsoft.Compute/virtualMachines/deallocate/action, .../start/action, .../write, and Microsoft.Compute/skus/read; on GCP compute.instances.stop, compute.instances.start, compute.instances.setMachineType, and compute.machineTypes.get.

• qumulo_threat_detection_azure gains an optional managed_identity_id attribute so operators can attach a user-assigned managed identity to the Threat Detection VM. When set, the VM uses SystemAssigned + UserAssigned identity, cloud-init requests Key Vault tokens via IMDS with that identity's client_id, and the provider grants Key Vault Secrets User on the TD bootstrap secrets to the UAMI principal. Destroy revokes those secret-scope assignments along with the secrets. When omitted, the VM uses SystemAssigned only. Changing the identity forces replacement.

• qumulo_threat_detection_aws gains an optional permissions_boundary_arn attribute so the provider-created Threat Detection instance role can satisfy accounts that deny iam:CreateRole unless a permissions boundary is attached. When omitted, the role is created without a boundary. Changing the ARN forces replacement (the boundary is set only at CreateRole). Bring-your-own instance roles are out of scope.

• qumulo_threat_detection_azure gains an optional key_vault_id attribute so operators can bring their own Key Vault for Threat Detection bootstrap secrets. When set, the provider looks up the vault (same subscription, Azure RBAC authorization required), writes cluster-namespaced secrets (td-cluster-access-token-<cluster-uuid>, td-admin-password-<cluster-uuid> so a shared vault can back multiple TD deployments; recovering soft-deleted names when needed), and grants the VM identity secret-scope RBAC; it never creates or deletes the customer vault. Destroy removes the provider-written secrets and their secret-scope role assignments. Computed keyvault_id / keyvault_uri still report the effective vault (equal to the input when BYO). The attribute is immutable after create; adopting BYO on an existing provider-managed deployment forces replacement. When omitted, the provider continues to create a dedicated vault with the short canonical secret names as before.

• qumulo_filesystem_aws, qumulo_filesystem_azure, qumulo_filesystem_gcp: cluster_uuid can now be set in configuration to adopt an existing cluster's UUID during terraform import when automatic recovery cannot find it. The value is rejected when creating a cluster and cannot be changed after adoption.

Changed

• qumulo_filesystem_aws now rejects an out-of-range floating_ip_count (anything other than 0 or 3-100) at plan time with a clear error instead of failing partway through apply.

Deprecated

• The floating_ips list on qumulo_filesystem_gcp is deprecated in favor of floating_ip_count. Supplying the list still works during the deprecation window: the provider adopts the listed addresses under its own management without changing them and derives the count from the list length, so an existing cluster migrates by replacing floating_ips = [...] with floating_ip_count = <list length>, with no address change and no cluster change. If both attributes are set they must agree (enforced at plan time). The attribute remains computed and always reflects the cluster's live floating IPs, so it stays useful as an output after migrating.

Fixed

• qumulo_threat_detection_aws, qumulo_threat_detection_azure, and qumulo_threat_detection_gcp no longer warn that the appliance "will be replaced" when an in-progress upstream cluster change merely leaves the cluster_reference values unknown at plan time (most commonly a floating-IP change on the referenced cluster). The destructive warning now fires only when a known, differing replacement-forcing value is present; pending values get a softer notice explaining that they do not, by themselves, replace the appliance.

• On Azure, any error message that merely contained the digits 404 (a correlation ID, an echoed response body) was treated as "resource not found". A live Threat Detection appliance or cluster resource could silently drop out of state on refresh, so the next plan proposed recreating it, and delete sweeps could skip a real resource as "already gone", leaving it behind and billing. Not-found is now decided by the actual HTTP 404 status or an explicit NotFound error code.

• Recreating qumulo_threat_detection_aws (a destroy-then-create or terraform apply -replace) no longer fails with You can't create this secret because a secret with this name is already scheduled for deletion. The provider now restores a secret still in its recovery window and rewrites its value, and retries with backoff while a force-deleted secret finishes purging; if the purge takes longer than the retry window, the error says to re-run apply in a few minutes.

1.4.4 - 2026-07-21

Added

• qumulo_threat_detection_azure gains optional custom_image_id and marketplace_image attributes to override the appliance VM's boot image, matching the image override already available on AWS and GCP. The two attributes are mutually exclusive; omit both to keep the default Canonical Ubuntu 24.04 LTS Marketplace image. Changing either forces replacement.

• qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp scale operations now verify that the requested Qumulo Core deb/rpm package actually exists before adding nodes, failing fast with a clear error instead of waiting indefinitely for the new nodes to fail (#693).

• qumulo_threat_detection_azure gains an optional allow_cidrs attribute for additional inbound source CIDRs (all protocols/ports) on top of the always-present VirtualNetwork cluster-reachability rule. Omit it to keep the historical VNet-only ingress. Public CIDRs open the appliance through its public IP; 0.0.0.0/0 or ::/0 triggers a plan-time warning. The attribute is updatable in place.

• qumulo_threat_detection_aws gains an optional allow_cidrs attribute for additional inbound source CIDRs (all protocols/ports) on top of the always-present VPC CIDR cluster-reachability rule. Omit it to keep the historical VPC-only ingress. The appliance has no public IP; CIDRs must reach it via VPC peering, VPN, or private connectivity. The attribute is updatable in place.

• qumulo_threat_detection_gcp gains an optional allow_cidrs attribute that sets the authoritative source CIDRs for the appliance's TCP/8000 ingress firewall rule, replacing the historical subnet-CIDR-only default. IAP SSH and egress rules are unchanged. Omit it to keep subnet-only ingress. The appliance has no public IP and an IPv4-only NIC; IPv6 prefixes are accepted by the firewall API but will not reach the VM. The attribute is updatable in place.

• qumulo_threat_detection_aws gains an optional additional_security_group_ids attribute so operators can attach org-mandated security groups to the appliance ENI alongside the provider-created security group. Omit or clear it to leave only the auto-created security group. Each ID must be in the appliance VPC. At most 15 IDs (AWS absolute maximum of 16 security groups per ENI including the provider-created group; account default quota is often 5). The attribute is updatable in place; out-of-band ENI security-group changes are not detected on refresh.

• qumulo_threat_detection_aws gains an optional kms_key_id attribute for customer-managed encryption of the appliance root EBS volume. When omitted, the volume uses the account default AWS-managed EBS key. Changing the key forces replacement. When set, the provider also grants the instance role the CMK-EBS permissions needed to use the key (prefer a key ID or key ARN; aliases encrypt the volume but do not produce a working IAM Resource grant).

• qumulo_threat_detection_gcp gains an optional kms_key_name attribute for customer-managed encryption of the appliance boot disk and both Secret Manager secrets (cluster bearer and admin password). When set, secrets use user-managed replication in the Threat Detection region with that regional key. Grant roles/cloudkms.cryptoKeyEncrypterDecrypter on the key to the Compute Engine and Secret Manager service agents. When omitted, Google-managed encryption is used. Changing the key forces replacement.

Changed

• The automatic admin-password upgrade for threat detection appliances deployed with provider versions before 1.4.2 has been removed: qumulo_threat_detection_aws, qumulo_threat_detection_azure, and qumulo_threat_detection_gcp no longer rotate an existing appliance's factory-default admin password on the next update. Appliances created with 1.4.2 or later are unaffected (their password is rotated at creation). To move an older appliance off the factory default, rotate its admin password by hand.

1.4.3 - 2026-07-17

Fixed

• On qumulo_filesystem_aws, changing or removing cluster_fqdn on a running cluster now reconciles the cluster's authoritative DNS configuration instead of being a silent no-op. Previously an in-place update that changed or cleared cluster_fqdn reported Apply complete! while leaving the cluster's authoritative DNS name unchanged; the update path now runs the provisioner to apply the new name or disable authoritative DNS when the attribute is removed.

1.4.2 - 2026-07-17

Added

• qumulo_filesystem_aws subnet_ids can now be changed in place: subnet and availability-zone topology changes (single-AZ ↔ multi-AZ), alone or combined with instance_type and node_count changes, perform a node-by-node cluster replacement that preserves cluster identity and data instead of destroying the cluster. New subnets must be in the same VPC.

• Converting qumulo_filesystem_aws from single-AZ to multi-AZ requires floating_ip_count to be 0 in the same change, enforced at plan time: AWS secondary private IPs are bound to a single subnet/AZ, so a multi-AZ cluster can't carry floating IPs. If the cluster still has floating IP ranges or authoritative DNS enabled from its single-AZ configuration, the replacement clears both before swapping the nodes.

• Converting multi-AZ back to single-AZ can raise floating_ip_count above 0 in the same apply: once the swap onto the single subnet completes, the replacement assigns floating IPs to the new nodes.

• qumulo_filesystem_gcp availability_zones can now be changed in place: zone topology changes (single-AZ ↔ multi-AZ), alone or combined with instance_type and node_count changes, perform a node-by-node cluster replacement that preserves cluster identity and data instead of destroying the cluster.

• qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp gain an optional cluster_fqdn attribute. When set, the cluster enables Qumulo Core authoritative DNS and answers queries for that name with its floating IPs (round-robin). It can be changed or removed in place; removing it disables authoritative DNS. cluster_fqdn requires at least one floating IP (enforced at plan time) and cluster_version 7.5.0 or newer (validated before provisioning begins, with an in-cluster runtime check). Delegating or forwarding the name to the cluster's floating IPs is your responsibility.

• qumulo_threat_detection_aws, qumulo_threat_detection_azure, and qumulo_threat_detection_gcp now rotate the appliance's admin account off the factory-default password during deployment. You can supply your own password with the new optional write-only td_admin_password attribute, or omit it to have the provider generate one. Either way the password is stored in your cloud's secret store (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) and never appears in Terraform state or boot logs; retrieve a provider-generated password via the new td_admin_password_secret_arn output on AWS or td_admin_password_secret_name on GCP (on Azure, look up the td-admin-password secret in the appliance's Key Vault). Appliances deployed with earlier provider versions are upgraded automatically on the next apply that updates the resource; if the appliance's password was already rotated by hand, the provider warns and leaves it alone.

Changed

• qumulo_filesystem_aws cluster nodes now receive S3 access through a single deployment-scoped bucket-name wildcard in their IAM role policy instead of a policy that lists every bucket individually. This removes the practical ceiling on soft_capacity_limit_tb: raising the limit no longer grows the IAM policy toward AWS's policy size cap, and no IAM policy update happens at all when buckets are added. If you bring your own IAM roles (cluster_iam_role_arn), update your policy to the wildcard pattern shown in the Bring Your Own IAM Roles guide.

Fixed

• On qumulo_filesystem_azure clusters that bring their own managed identity and network security, node replacement and scale-up previously launched the new VMs with the wrong identity configuration and attempted role assignments the deployment had opted out of, causing the operation to fail after a long timeout. Replacement and scale-up VMs now inherit the cluster's configured identity, security group association, and disk settings exactly as cluster create does.

• On qumulo_filesystem_aws, changing floating_ip_count on a running host_managed cluster previously reported Apply complete! without reconciling anything: the update path never compared the desired count against the cluster's actual allocated floating IPs, so nothing was assigned or unassigned. It now detects the mismatch, assigns or unassigns ENI secondary IPs to match the new count, and updates the cluster's floating-IP ranges accordingly.

1.4.1 - 2026-07-14

Added

• qumulo_filesystem_gcp: changing node image fields (node_image, node_image_project, node_image_family) now performs an in-service node replacement — new nodes running the requested image join the cluster and the old nodes are retired, preserving the cluster UUID, endpoint IPs, and data — instead of planning a full cluster destroy-and-recreate. A pinned node_image is now also honored during instance-type replacements (previously the pin was ignored and the replacement resolved the image family instead, which failed outright for pinned clusters). This also fixes a silent no-op where adding a first-time node_image pin to a cluster created without one reported Apply complete! while leaving the VMs untouched and state drifted (#649).

1.4.0 - 2026-07-13

Breaking

• qumulo_filesystem_aws: s3_storage_class is renamed to storage_class. Rename the attribute in your configuration. The old state value is dropped on upgrade and the attribute is re-derived from cluster_product_type, so if your cluster runs a non-default class (for example a COLD cluster created when the default was STANDARD_IA), set storage_class explicitly to the class the cluster actually uses; otherwise Terraform state records the current default instead of the deployed class. The deployed cluster is unaffected either way, since the value is only consumed at create time.

Added

• storage_class on qumulo_filesystem_azure selects the storage backing the cluster's persistent data. HOT clusters accept STANDARD (Hot-tier storage accounts, plain hot storage) or INTELLIGENT_TIERING (Smart-tier storage accounts, intelligent tiering; requires Qumulo Core 7.8.4 or newer). COLD clusters use STANDARD. Defaults preserve existing behavior (INTELLIGENT_TIERING on Core 7.8.4+, STANDARD otherwise), so the new attribute's job is letting you opt out of intelligent tiering. Immutable after creation.

• Cluster creation now rides out transient cloud "insufficient capacity" shortages instead of failing immediately. When a cloud has no capacity for the requested instance type in the target zone, qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp retry each node's launch with jittered backoff for up to 60 minutes (bounded by your Terraform create timeout, and only for genuine capacity/allocation-exhaustion errors, never quota or unavailable-SKU errors). This behavior also covers scale-up and node-replacement. Set TF_LOG=WARN to see the retry progress. Behavior change: a sustained shortage now takes up to ~60 minutes to surface as a failure instead of ~1 minute, which matters for CI/automation with tight timeouts.

• Cluster node disks now carry a drive-type suffix in their cloud console name, using the same vocabulary on all three clouds: -osdisk (boot), -wcache-1..N (write cache), and -dkv-1..N (key-value store), for example mydeployment-node-1-dkv-2. On AWS the suffix appears in each EBS volume's Name tag; on Azure and GCP it is the disk resource name. This makes it easy to tell at a glance which disk plays which role when troubleshooting a node. Applies to nodes created by cluster create, scale-up, and node replacement going forward; disks on existing nodes keep their current names (Azure and GCP disk names are immutable, and mixed old/new naming within a cluster is fully supported, including clusters imported from the legacy CNQ Terraform modules).

• qumulo_filesystem_aws now accepts cluster_iam_role_arn and provisioner_iam_role_arn for organizations that pre-provision IAM. When set, the provider performs no IAM writes for that role — no creation, policy updates, tagging, or deletion — and instead launches instances with your role's instance profile. The two attributes are independent, and each requires the role to be in exactly one instance profile. The deploying credentials need iam:PassRole and iam:ListInstanceProfilesForRole on the supplied roles, and your S3 policy must use the bucket-name wildcard pattern from the new Bring Your Own IAM Roles guide (pick deployment_name before creating the roles). Changing either attribute forces cluster replacement.

• New optional skip_provisioner_cleanup flag on the provider block. When true, a successful cluster create leaves the temporary provisioner VM and its dependent resources in place instead of deleting them, which is useful for capturing logs when diagnosing a provisioning problem. The retained resources keep incurring cost until the next terraform apply removes them or you delete them by hand, so leave it off for normal operation.

• qumulo_filesystem_aws now supports the m7i instance family (m7i.xlarge through m7i.48xlarge). Like m6i, m7i instances have no local NVMe storage, so the provider builds the read cache on EBS: one 1 TiB gp3 volume per read-cache slot (up to 24 on m7i.48xlarge) at 12,500 IOPS / 525 MB/s, named <node>-rcache-<n>. EBS-read-cache instance types require Qumulo Core 7.4.3 or later, enforced at plan time.

• Every cloud resource created by qumulo_filesystem_aws, qumulo_filesystem_azure, qumulo_filesystem_gcp, and the corresponding qumulo_threat_detection_* resources now carries a qumulo-deployment tag (label on GCP) naming the deployment that owns it, so disks and other resources are attributable at a glance in the cloud console. Filesystem resources use the deployment_unique_name; threat detection resources use their appliance naming seed (<cluster_name>-td-<suffix>). The tag is provider-managed: a tags entry with the same key is overridden, and removing one never strips it. Existing deployments pick the tag up the next time resource tags are updated.

Breaking

• cluster_api_dns_name on qumulo_threat_detection_aws, qumulo_threat_detection_azure, and qumulo_threat_detection_gcp now accepts DNS hostnames only. IP address literals (IPv4 and IPv6, including bracketed IPv6 added in v1.3.8) are rejected at plan time. Because the attribute is ForceNew, an existing config that used an IP literal will fail terraform plan after upgrade; switching to a DNS hostname forces the Threat Detection appliance to be replaced. Upgrade: create an internal DNS record or load-balancer hostname that resolves to the cluster REST API, set cluster_api_dns_name to that name, and allow one apply to replace the appliance if you are migrating from an IP literal.

Fixed

• A scale-up or node-replacement that fails while launching the new nodes (for example, a sustained capacity shortage after the retry window) now cleans up the partially created resources instead of leaving them running and billing: the new instances/VMs are terminated on all three clouds, along with the fresh AWS placement group and, on Azure, the new nodes' NICs, disks, and managed-identity role assignments. Cleanup runs even when the failure was the update timeout itself, and never touches the existing cluster. Nodes that may have already joined the cluster (the provisioner had started) are deliberately left in place, since removing them could damage cluster membership; the error message says what remains. On GCP this also removes an unsafe behavior where a scale-up whose provisioner failed mid-join would delete VMs that might already be cluster members.

• On Azure, replacement nodes in clusters that use custom node naming now receive the cluster's configured names instead of default-pattern names.

• On Azure, tag updates now reach every data disk on node sizes with more than ten data disks, and disks from any naming generation (including clusters imported from legacy CNQ Terraform modules).
• On AWS, a tags entry named Name, or the removal of one, no longer overwrites or deletes the provider-managed Name tag on cluster instances, volumes, and network interfaces.
• On Azure, cluster create and scale operations no longer fail with a MismatchingNestedResourceSegments error when the subscription automatically installs the Azure Monitor Agent (or another VM extension) onto cluster nodes outside of Terraform. Data-disk attach and detach now use a partial VM update that leaves such externally-managed extensions untouched.
• On Azure, tag updates that touch the deployment's resource group no longer fail because the provider echoed a read-only field back to Azure.
• m6i deployments now actually provision their EBS read cache. Previously the provider created m6i clusters with no read-cache volumes at all, leaving them severely under-cached. New m6i clusters get the read-cache volumes and the boot-time configuration that classifies them; nodes added to or replaced in an existing m6i cluster also get them (mixed old/new topology within a cluster is supported). Note that m6i (like m7i) now requires Qumulo Core 7.4.3 or later; an existing m6i configuration pinned to an older cluster_version will fail terraform plan after upgrading the provider.
• Updating tags on qumulo_filesystem_azure no longer strips the provider's internal node-identity tags (qq:node_id, qq:node_role) from cluster VMs.
• On qumulo_filesystem_aws, in-place updates that run the provisioner (such as changing soft_capacity_limit_tb or floating-IP settings) no longer fail with MissingParameter: ImageId on clusters that did not set provisioner_ami_id. The update path now resolves the default provisioner image just before launching the temporary provisioner instance, the same way cluster create does.

Changed

• ENA Express is now enabled on every instance size whose hardware supports it: m6i.8xlarge and larger, m6idn.8xlarge and larger, and i7ie.3xlarge/i7ie.6xlarge were previously left off and now turn on. Existing clusters on these types pick up ENA Express the next time the provisioner runs (next terraform apply that touches the cluster).
• qumulo_filesystem_azure no longer writes the qq:deployment (cluster VMs/NICs) and deployment (provisioner VM) tags; both are replaced by the uniform qumulo-deployment tag. Stale copies on existing VMs are removed on the next tag update.

1.3.10 - 2026-07-02

Added

• You can now run your own shell snippets during cluster boot. qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp accept optional provisioner_hooks and node_hooks blocks, each with a pre_run and post_run script. This is handy for site-specific setup like installing monitoring agents, trusting an internal CA, or registering nodes with your inventory system. Hooks run as root and should be idempotent; avoid embedding secrets, since hook contents appear in boot logs and Terraform state. The Customizing Cluster Boot guide covers exactly when each hook runs and which shell variables are available.

• qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp now check at plan time that an increase to soft_capacity_limit_tb stays under 5 PB (5000 TB) per apply, which is the largest single step a Qumulo cluster accepts. Instead of finding this out during apply, you get a clear plan error that names the highest value you can set right now; larger increases are a matter of a few sequential applies. Decreases are not step-limited.

Fixed

• Capacity increases on qumulo_filesystem_aws and qumulo_filesystem_gcp are now more resilient: if an apply that raises soft_capacity_limit_tb is interrupted or fails partway, simply running terraform apply again picks up where the previous attempt left off and completes cleanly.

1.3.9 - 2026-07-01

Added

• New deletion_protection attribute on qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp. When enabled, the cluster's compute instances and backend storage cannot be deleted, even from the cloud console or CLI. Each cloud uses its native protection mechanism:
• AWS: EC2 termination protection on the instances, plus a bucket-policy deny on s3:DeleteBucket for the S3 buckets. The deploying credentials need ec2:ModifyInstanceAttribute, ec2:DescribeInstanceAttribute, and s3:GetBucketPolicy.
• Azure: CanNotDelete management locks on the VMs and storage accounts. The deploying principal needs the Microsoft.Authorization/locks/* permission (Owner, User Access Administrator, or a custom role; Contributor alone is not enough). The provider verifies this at plan time.
• GCP: the native deletionProtection flag on each node instance. GCS buckets have no equivalent cloud-side mechanism, so they are protected by the terraform destroy gate only.

To delete a protected cluster, set deletion_protection = false, run terraform apply, then run terraform destroy. Day-to-day operations like scaling and node replacement work normally while protection is on, and the provider re-asserts protection on every apply.

• New deletion_protection attribute on qumulo_threat_detection_aws, qumulo_threat_detection_azure, and qumulo_threat_detection_gcp. When enabled, the appliance VM carries the same cloud-native protection (EC2 termination protection, an Azure CanNotDelete management lock, or GCP's deletionProtection flag), and terraform destroy (or any change that would replace the appliance) is refused. To remove the appliance, set deletion_protection = false and apply first, then destroy. The Azure permission requirement above applies here too.

Fixed

• qumulo_filesystem_azure clusters created with provider 1.3.8 could silently disappear from Terraform state. The provider stored the deployment name without its random suffix, so the first terraform refresh could not find the deployment, dropped it from state, and the next terraform apply provisioned a duplicate cluster. New clusters now store the correct suffixed name. If a 1.3.8 cluster has already been dropped from your state, recover it with terraform import.
• qumulo_filesystem_gcp cluster creation could hang until timeout on provider 1.3.8. Node instances were tagged with the unsuffixed deployment name while the firewall rules targeted the suffixed one, leaving nodes unreachable on the cluster API port so the cluster never formed. New clusters now tag nodes correctly. A cluster stuck this way can be unblocked in place by adding the <deployment_unique_name>-cluster network tag to each node instance.
• The first terraform apply after importing qumulo_filesystem_aws, qumulo_filesystem_azure, or qumulo_filesystem_gcp no longer fails with "Provider produced inconsistent result after apply" on cluster_name and deployment_name. The post-import plan now resolves both values from your configuration, as the import guide describes.

1.3.8 - 2026-07-01

Added

• qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp now validate at plan time that the chosen instance type is compatible with the selected soft_capacity_limit. Incompatible combinations fail fast at terraform plan with a clear error instead of during cluster provisioning.

Changed

• New clusters now receive an immutable randomly generated suffix in their deployment_unique_name (for example, mycluster-h12g9v). This is the stable identifier used to name and tag every cloud resource for the deployment's life. The deployment_name attribute now accepts up to 36 characters (previously 15) to accommodate the full seeded value. Existing clusters are unaffected: updates and imports read the persisted name from state.

Fixed

• cluster_api_dns_name on qumulo_threat_detection_aws, qumulo_threat_detection_azure, and qumulo_threat_detection_gcp now accepts bracketed IPv6 literals (e.g. [2001:db8::1]). The brackets are stripped before net.JoinHostPort so the provider dials correctly; the original bracketed form is preserved for cloud-init.

1.3.7 - 2026-06-29

Added

• cluster_name and deployment_name attributes on qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp. These let you name the Qumulo cluster (the name shown in the Qumulo UI, case preserved) separately from deployment_name, the lowercase prefix used for all cloud infrastructure (instances, disks, buckets, IAM roles, security groups, etc.). Set the cluster_name + deployment_name pair to decouple them, or keep using name as a back-compatible shortcut that sets both. Exactly one form must be set; mixing name with either of the pair is rejected.

Added

• Optional cluster_api_dns_name on qumulo_threat_detection_aws, qumulo_threat_detection_azure, and qumulo_threat_detection_gcp. Use this when the protected cluster does not configure floating IPs: set it to a stable hostname or IP (no port) for the cluster REST API (TCP 8000). It must resolve and be reachable from the host running terraform apply (the provider preflights connectivity and bootstraps cluster-side credentials through it) and from the Threat Detection VM (which calls that API whenever it needs the current backend node IP addresses — including after scaling or node replacement — then communicates with those nodes directly). Mutually exclusive with floating IPs on the filesystem; cluster_reference is always required.

Changed

• On terraform import of qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp, the cluster name is no longer inferred from the deployment name. Declare name (or the cluster_name + deployment_name pair) in your configuration to match the running cluster; the first post-import plan sets these values in place without replacing the cluster. This makes importing clusters whose deployment_unique_name carries a random suffix — including clusters created by the legacy aws-terraform-cnq, azure-terraform-cnq, and qumulo-terraform-gcp modules — reliable, where it could previously plan a spurious cluster replacement.

Added

• qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp now expose cluster_api_endpoint inside their computed cluster_reference output: the single cluster API target downstream resources dial (equals endpoint_ips[0]). Threat Detection keys appliance replacement on this stable field instead of the whole endpoint_ips list.

Changed

• Scaling a Threat Detection–protected cluster (changing node_count) no longer replaces the qumulo_threat_detection_* appliance when a stable cluster REST API entry point is configured (floating IPs, or cluster_api_dns_name). Replacement is keyed on cluster identity/placement fields and cluster_api_endpoint in float mode — not the volatile endpoint_ips list. The cluster resources also keep cluster_reference stable at plan time across in-place updates so the downstream reference no longer churns to (known after apply).
• When a qumulo_threat_detection_* appliance will be replaced, terraform plan now emits a warning that names exactly which cluster_reference value changed (for example cluster API endpoint (cluster_api_endpoint) or cluster identity (cluster_uuid)), replacing the previous opaque "cluster_reference forces replacement" diff.

Fixed

• qumulo_filesystem_aws COLD clusters now default s3_storage_class to GLACIER_IR instead of STANDARD_IA. GLACIER_IR is the intended archival default; the previous STANDARD_IA default was incorrect. Clusters that already specify s3_storage_class (explicitly or via a prior apply) are unaffected, since the value is immutable after creation. To keep STANDARD_IA on a new COLD cluster, set s3_storage_class = "STANDARD_IA" explicitly.
• terraform import of a qumulo_filesystem_aws cluster now keeps floating_ip_count customer-declared. Previously, import derived the count from the discovered floating IPs; for clusters using the qumulo_managed networking mode (where Qumulo Core owns the floating IPs) this stamped a non-zero count into state and drove destructive floating-IP reconciliation. Floating-IP reconciliation is now skipped entirely in the qumulo_managed networking mode.

Breaking

• qumulo_threat_detection_aws, qumulo_threat_detection_azure, and qumulo_threat_detection_gcp now require a stable cluster REST API entry point: either floating IPs on the protected filesystem (cluster_reference.uses_floating_ips = true) or cluster_api_dns_name on the Threat Detection resource. Without one of these, the appliance would target a volatile node primary IP and be replaced on every cluster change. terraform plan/apply fails fast when neither is configured, or when both are.

Upgrade notes: configure floating IPs on the qumulo_filesystem_* cluster resource (floating_ip_count on qumulo_filesystem_aws; floating_ips on qumulo_filesystem_azure and qumulo_filesystem_gcp), or set cluster_api_dns_name on the Threat Detection resource to a stable hostname or IP that resolves and reaches the cluster REST API from the host running terraform apply and from the Threat Detection VM. Adding floating IPs or introducing cluster_api_dns_name may replace the Threat Detection appliance once on the first apply; subsequent cluster scaling will not when the stable entry point is configured.

# Option A: floating IPs on the filesystem
resource "qumulo_filesystem_aws" "cluster" {
  # ...
  floating_ip_count = 3
}

resource "qumulo_threat_detection_aws" "td" {
  cluster_reference = qumulo_filesystem_aws.cluster.cluster_reference
  # ...
}

# Option B: cluster_api_dns_name when the filesystem has no floating IPs
resource "qumulo_threat_detection_aws" "td" {
  cluster_reference     = qumulo_filesystem_aws.cluster.cluster_reference
  cluster_api_dns_name  = "qumulo-api.internal.example.com"
  # ...
}

1.3.6 - 2026-06-17

Changed

• qumulo_filesystem_aws and qumulo_threat_detection_aws now launch EC2 instances with IMDSv2 (Instance Metadata Service v2) required by default, hardening cluster and appliance instances against SSRF-style metadata theft. No configuration change is required.

1.3.5 - 2026-06-16

Added

• AWS cluster provisioning logs are now streamed to CloudWatch Logs, giving operators visibility into what happened during a deployment (parity with GCP Cloud Logging). The provisioner's IAM role gains the CloudWatch Logs permissions required to create log groups and write log events.

Changed

• nexus_registration_key on qumulo_filesystem_aws, qumulo_filesystem_azure, and qumulo_filesystem_gcp is now a write-only attribute. The single-use Nexus onboarding OTP is sent to the provider during apply but is no longer persisted to terraform.tfstate, so the secret cannot leak from the state file. No configuration change is required, but write-only attributes require Terraform CLI 1.11 or later.
• qumulo_filesystem_gcp now lets you reset a pinned node image from configuration alone: set the image name to an empty string to fall back to the image project/family, or empty the project/family to return to the provider defaults, instead of having to edit terraform.tfstate.
• qumulo_filesystem_gcp now surfaces a Terraform warning diagnostic when it falls back to a coined cluster UUID, so the fallback is visible during plan/apply instead of happening silently.

Fixed

• qumulo_filesystem_azure now removes all cluster data disks on destroy by enumerating the disks in the resource group, rather than predicting their names. Disks whose names did not match the predicted pattern are no longer left orphaned.
• qumulo_filesystem_azure and qumulo_filesystem_gcp normalize unknown floating_ips values before syncing cluster_reference, avoiding spurious diffs and apply-time errors when the floating-IP set is not yet known.
• qumulo_filesystem_gcp project IAM updates now use a condition-aware read-modify-write with backoff, so transient conflicts are retried and existing conditional IAM bindings are no longer clobbered.

Breaking

• qumulo_filesystem_azure no longer exposes the disable_public_network_access attribute. The storage accounts backing the cluster are now always created with public network access restricted to selected networks, permitting only the cluster subnet via a VNet rule (deny-by-default NetworkRuleSet, with the trusted-Microsoft-services bypass). This requires the Microsoft.Storage service endpoint on the cluster subnet; the provider fails fast at create time if it is missing. The new scoping applies to newly created clusters only, so existing clusters are not re-scoped.

Upgrade notes: remove disable_public_network_access from any qumulo_filesystem_azure configuration that sets it, and ensure the cluster subnet has the Microsoft.Storage service endpoint enabled before creating a cluster.

# Before
resource "qumulo_filesystem_azure" "cluster" {
  disable_public_network_access = true
  # ...
}

# After
resource "qumulo_filesystem_azure" "cluster" {
  # disable_public_network_access removed; storage accounts are
  # automatically scoped to the cluster subnet.
  # ...
}

1.3.4 - 2026-06-16

Changed

• qumulo_filesystem_gcp no longer rejects configurations that set both a specific node image and an image project/family. When both are set, the explicit image name takes priority and the project/family pair is used only as a fallback.

Fixed

• qumulo_filesystem_aws deployments no longer fail when the generated instance user-data exceeds the EC2 16 KB limit. The user-data script is now gzip-compressed before launch.

1.3.3 - 2026-06-16

Changed

• qumulo_filesystem_azure now fails the apply when the storage SAS token cannot be created during initial cluster setup, instead of swallowing the error and leaving the cluster misconfigured.

1.3.2 - 2026-06-15

Fixed

• Cluster installation no longer fails when the Qumulo Core package needs more room than the default /var partition provides. Node bootstrap now expands /var before installing the package, across AWS, Azure, GCP, and bare-metal deployments.

1.3.1 - 2026-06-15

Added

• s3_storage_class on qumulo_filesystem_aws lets you choose the S3 storage class backing the cluster's persistent storage. HOT clusters accept STANDARD or INTELLIGENT_TIERING (default INTELLIGENT_TIERING); COLD clusters accept STANDARD_IA or GLACIER_IR (default STANDARD_IA). Defaults are unchanged, so existing configs apply exactly as before. Immutable after creation.
• Support for 4-node single-AZ AWS clusters.
• GCP cluster installation logs are now streamed to Cloud Logging, giving operators visibility into what happened during a deployment.

Changed

• AWS and Azure cluster names may now contain uppercase letters and dashes. Underlying cloud resources continue to use the lowercased name.
• AWS cluster nodes now launch in an EC2 placement group for better inter-node network performance. Changing the instance type provisions a new placement group, per AWS guidance.

Breaking

• qumulo_filesystem_aws.permissions_boundary was renamed to permissions_boundary_arn to clarify that the value is an IAM policy ARN.

Upgrade notes: rename the attribute in any qumulo_filesystem_aws configuration that sets it. No cluster changes result from the rename.

# Before
resource "qumulo_filesystem_aws" "cluster" {
  permissions_boundary = "arn:aws:iam::123456789012:policy/my-boundary"
  # ...
}

# After
resource "qumulo_filesystem_aws" "cluster" {
  permissions_boundary_arn = "arn:aws:iam::123456789012:policy/my-boundary"
  # ...
}

1.3.0 - 2026-06-10

Added

• qumulo_threat_detection_aws resource for deploying Qumulo Threat Detection appliances alongside AWS clusters. Configuration mirrors the Azure shape — wire cluster_reference from the cluster and supply the admin password; region, VPC, and CIDR derive automatically.
• qumulo_threat_detection_gcp resource for deploying Qumulo Threat Detection appliances alongside GCP clusters. Uses the IAP access model; project_id, region, and subnet_cidr derive automatically from cluster_reference.
• cluster_reference computed output on qumulo_filesystem_aws and qumulo_filesystem_gcp for wiring downstream resources (e.g. Threat Detection) to the cluster.
• nexus_organization computed attribute on qumulo_filesystem_aws and qumulo_filesystem_gcp (parity with qumulo_filesystem_azure). terraform plan surfaces the operator-visible Nexus organization label the cluster will be onboarded to BEFORE the operator commits, so cross-organization onboarding mistakes are visible pre-apply. Rendered as Name (organization ID N) when the org name resolves, else organization ID N. Null when nexus_api_token is not configured. Immutable historical record — preserved across refreshes via UseStateForUnknown.
• region, vpc_id, and vpc_cidr computed sub-attributes on qumulo_filesystem_aws.cluster_reference, populated during Create (CIDR via DescribeVpcs, best-effort: a failed call leaves CIDR empty rather than failing the apply).
• Configurable Nexus host for GCP clusters (parity with AWS and Azure).
• Per-operation timeout defaults on AWS and Azure cluster + Threat Detection resources are now documented in the schema descriptions and generated docs, so operators no longer need defensive timeouts {} blocks to size for Hot CNQ wall-clock.

Changed

• AWS Threat Detection apply now blocks until the appliance finishes bootstrapping (parity with Azure and GCP), so terraform apply returns only when Threat Detection is actually ready instead of while the appliance is still provisioning.
• qumulo_filesystem_gcp.soft_capacity_limit_tb is now Optional + Computed with a default of 500 instead of Required.
• AWS and GCP clusters now auto-pre-register with Nexus and coin their cluster UUID up front (matching Azure), so the cluster's Nexus dashboard row and UUID exist before the cluster boots.
• qumulo_filesystem_azure now validates the operator's required Azure RBAC permissions at plan time and fails the apply — instead of only warning — when App Configuration / Key Vault role grants or admin-password storage do not succeed, so permission gaps surface before they cause silent cluster_uuid drift.
• Nexus permission errors now name the Nexus role the operator is missing (instead of internal ability identifiers), and the nexus_api_token is validated at plan time so missing-permission failures surface during terraform plan rather than mid-apply.

Deprecated

• nexus_registration_key on the filesystem resources (including qumulo_filesystem_gcp) is deprecated in favor of nexus_api_token-based onboarding.

Fixed

• Smart defaults for AWS and GCP Threat Detection placement attributes and qumulo_threat_detection_azure.resource_group_name now run in ModifyPlan, so re-derivation on replacement and stale-state recovery are handled correctly. When cluster_reference changes such that the derived value should change (e.g. cluster moved to a new region or resource group), the new value is picked up on the next plan without requiring an explicit override or destroy + re-create.
• Nexus dashboard rows are now decommissioned on destroy, create-failure, and cluster-UUID divergence across AWS, Azure, and GCP, so failed or replaced deployments no longer leave orphaned rows (on divergence both the coined and the booted UUID are cleaned up).
• qumulo_filesystem_aws recovers the cluster name on import, avoiding a spurious post-import replacement diff; AWS cluster-name validation and Nexus tag-policy violations now surface as clear, actionable plan/apply errors.
• Threat Detection registration and cleanup are more resilient: the provider preflights cluster-API reachability before making changes, adopts and cleans up pre-existing cluster-side TD artifacts, and automatically revokes and retries when a stale Nexus TD secret blocks re-registration.
• GCP subnetwork self-links are normalized and image-pair attributes finalized, preventing spurious replacement plans.

Breaking

• qumulo_threat_detection_aws.cluster_reference input schema gained three new Required sub-attributes (region, vpc_id, vpc_cidr), and qumulo_threat_detection_aws.region/vpc_id/vpc_cidr flipped from Required to Optional + Computed at the top level. Operators who set the top-level values explicitly keep working unchanged; operators who omit them now have the values derived from cluster_reference.

Upgrade notes: qumulo_threat_detection_aws was pre-release in prior builds. Existing pre-release Threat Detection AWS state will fail to decode on the next plan — destroy any in-flight pre-release resources before upgrading:

# From the directory managing the pre-release TD resource, before upgrading:
terraform destroy -target='qumulo_threat_detection_aws.<name>'

New deployments are unaffected.

1.2.5 - 2026-05-28

Added

• qumulo_threat_detection_azure resource for deploying Qumulo Threat Detection appliances alongside Azure clusters.
• cluster_reference computed output on qumulo_filesystem_azure for wiring downstream resources (e.g. Threat Detection) to the cluster.
• azure.provisioning_timeout_minutes provider attribute (5–240, default 30) to extend the cluster provisioning wait when targeting slower environments.
• qumulo_audit_cloudwatch IAM policy now grants logs:DescribeLogGroups and logs:DescribeLogStreams, which Qumulo Core 7.9.0 audit V2 requires for writing audit events to CloudWatch Logs.

Changed

• Cluster provisioning progress now logs at INFO with a 60s heartbeat and emits a warning when the status appears hung for half the timeout. Timeout errors include the last observed status and how long it was stuck, so post-mortems no longer require log scraping.
• qumulo_filesystem_azure Create grants the operator's identity App Configuration Data Reader, preventing 403 errors and silent cluster_uuid regressions on subsequent terraform refresh runs.
• qumulo_filesystem_gcp zone lists are now sorted on read, so provider-discovered ordering no longer triggers replacement plans.

Fixed

• qumulo_filesystem_azure host-managed networking no longer fails on reboot because of a malformed MTU edit. The provider now writes a self-contained netplan drop-in (60-qumulo-mtu.yaml) instead of sed-editing 50-cloud-init.yaml at the wrong indent level.
• qumulo_filesystem_azure parses any cluster node ID format encountered during scale operations, using the unified node-ID parser shared across cloud providers.

1.2.4 - 2026-05-13

Added

• qumulo_filesystem_gcp terraform import support, including clusters originally deployed via the legacy qumulo-terraform-gcp module. Import recovers floating IPs (from primary-interface alias ranges), KMS key, node boot disk size, image family and project, and the cluster's zones.

Removed

• network attribute on qumulo_filesystem_gcp. The attribute had no effect: Terraform always reset it to null on the first apply. Remove it from your config if set.

Fixed

• qumulo_filesystem_azure no longer panics with invalid memory address or nil pointer dereference when Azure's storage RP returns a success response with no account ID (typically caused by a name reserved by a soft-deleted account in the same subscription). The provider now returns a clear error pointing at the naming template.
• qumulo_filesystem_gcp create no longer fails with "Provider produced inconsistent result after apply" on the network and related fields. Affected attributes are now correctly marked computed and preserved across applies.

1.2.3 - 2026-05-08

Added

• qumulo_filesystem_aws bring-your-own security groups via cluster_security_group_id and provisioner_security_group_id, for cross-account / RAM-shared subnet deployments. allow_cidrs is optional when BYO IDs are supplied.
• primary_ips computed attribute on qumulo_filesystem_azure, mirroring AWS and GCP.
• qumulo_filesystem_gcp supports changing floating_ips in place, and the provider now manages the GCP IAM role required for floating-IP runtime configuration.

Changed

• qumulo_filesystem_aws and qumulo_filesystem_gcp no longer force MTU 1400 on host-managed networking. AWS picks up the EC2 default (9001 jumbo on modern ENA); GCP picks up the VPC default. Azure unchanged.

Fixed

• Provider archives for linux and darwin extract with the executable bit set, fixing fork/exec ... permission denied on v1.2.2.
• qumulo_filesystem_aws cluster security-group rule updates reconcile (authorize new before revoking old) instead of revoking everything first, so a quota or permission error mid-update no longer leaves the cluster unreachable. Provisioner cross-SG ingress rules are preserved across allow_cidrs updates.
• qumulo_filesystem_azure cluster replacement and host-managed networking now grant the same RBAC and subnet-join roles as scale-up, so replacement VMs authenticate to the subscription and floating IPs attach when the subnet lives in a different resource group.
• qumulo_filesystem_gcp floating IPs now work end-to-end across create, scale, replace, and destroy.

1.2.2 - 2026-05-04

Added

• qumulo_filesystem_aws import compatibility with the upstream aws-terraform-cnq module. Cluster nodes are now discovered by Qumulo-Cluster=<deployment_name> tags, and the provider tolerates upstream node-name formats (<deploy>-node<N>) so imported clusters support the full lifecycle: read, update, scale, replace, and destroy.
• networking_mode attribute on qumulo_filesystem_gcp, matching the AWS and Azure schemas.

Changed

• networking_mode on qumulo_filesystem_aws is now immutable after cluster creation. Plan-time changes are blocked instead of silently destroying and recreating the cluster, matching Azure's behavior.

Fixed

• qumulo_filesystem_aws no longer fails scale or replacement operations with MissingParameter: ImageId when ami_id was omitted from configuration. The resolved AMI is now persisted in state and reused on update paths.
• terraform destroy for qumulo_filesystem_aws in AWS GovCloud no longer leaves orphaned IAM roles. Managed-policy and S3 bucket ARNs now derive their partition from the cluster region instead of hardcoding arn:aws:.

Breaking

• networking_mode on qumulo_filesystem_aws renamed its accepted values: "eni" is now "host_managed" (the new default) and "standard" is now "qumulo_managed". The behavior is unchanged. Existing configs that set networking_mode explicitly must be updated.

Upgrade notes: Update any explicit networking_mode values on qumulo_filesystem_aws:

# Before (1.2.1 and earlier)
resource "qumulo_filesystem_aws" "example" {
  # ...
  networking_mode = "eni"       # or "standard"
}

# After (1.2.2+)
resource "qumulo_filesystem_aws" "example" {
  # ...
  networking_mode = "host_managed"   # or "qumulo_managed"
}

If networking_mode was unset, no action is required: the new "host_managed" default is identical to the previous "eni" default.

1.2.0 - 2026-04-30

Added

• qumulo_filesystem_gcp reaches general availability. Full cluster lifecycle (create, scale up/down, replace, destroy) on Google Cloud with multi-zone deployments, image pinning via marketplace_image and provisioner_marketplace_image, hyperdisk and local SSD support, write/read cache disks, floating IPs, and label propagation. instance_type changes are supported via cluster replacement.
• qumulo_filesystem_aws multi-AZ cluster deployments.
• qumulo_filesystem_aws floating IP support, allocated at RunInstances time.
• qumulo_filesystem_aws server-side encryption for S3 buckets using customer-managed KMS keys.
• qumulo_filesystem_aws RHEL 8, 9, and 10 image support.
• qumulo_filesystem_aws terraform import support.
• qumulo_filesystem_aws availability zones are now validated against the EC2 API at plan time.

Breaking

• account_id and partition removed from the aws {} provider block. The partition is now derived from each resource's region (e.g. us-gov-* -> aws-us-gov), and the account ID is auto-detected via STS.

Upgrade notes: Drop account_id and partition from your AWS provider config:

# Before (1.1.3 and earlier)
provider "qumulo" {
  aws {
    account_id = "123456789012"
    partition  = "aws-us-gov"
    profile    = "gov-cloud"
  }
}

# After (1.2.0+)
provider "qumulo" {
  aws {
    profile = "gov-cloud"
  }
}

1.1.3 - 2026-04-14

Fixed

• Custom naming config now correctly applies to VM lookup and storage cleanup during destroy on Azure.

1.1.2 - 2026-04-12

Added

• Custom naming block (naming) for Azure VMs and storage accounts, allowing custom name templates with {node_id} and {index:N} placeholders.
• Customer-managed Key Vault support (key_vault_id) for Azure clusters, letting customers bring their own vault instead of the provider creating one.
• RHEL image support for Azure node and provisioner VMs via marketplace_image and provisioner_marketplace_image.
• soft_capacity_limit_tb attribute for setting storage capacity (50-10000TB).

Changed

• allow_cidrs is now required for Azure clusters.

Fixed

• Custom naming config now correctly applies to storage account URIs in the provisioner script.
• Storage private endpoint and DNS zone group names now use the deployment name prefix.

1.1.1 - 2026-03-19

Changed

• admin_password on qumulo_filesystem_azure, qumulo_filesystem_baremetal, and qumulo_filesystem_edge_baremetal is now write-only. The password is no longer stored in Terraform state, improving security. Existing state will drop the stored value on the next apply.

Fixed

• qumulo_local_user, qumulo_replication_target, qumulo_ldap_settings, qumulo_cluster_ssl, qumulo_smb_share, qumulo_portal, qumulo_portal_spoke, qumulo_portal_hub, qumulo_audit_cloudwatch, qumulo_audit_syslog, qumulo_time_configuration, qumulo_web_ui_settings, qumulo_s3_access_key, qumulo_smb_settings, and qumulo_filesystem_azure no longer cause perpetual diffs on computed or optional+computed attributes after apply.
• qumulo_nfs_export now preserves plan values through Create and Update, preventing inconsistent state after apply.
• qumulo_s3_bucket_policy no longer reports inconsistent state due to JSON formatting differences between the plan and API response.
• qumulo_portal_spoke_root and qumulo_portal_root import no longer forces replacement due to missing path fields in the import ID.
• qumulo_s3_bucket import now sets correct defaults for create-only boolean attributes.
• qumulo_s3_access_key import now sets the correct string value instead of an unknown marker.
• All resources now validate that import ID parts are not empty, returning a clear error instead of failing on a subsequent API call.
• Import log messages no longer contain sensitive data.
• qumulo_replication_object local_directory_path and qumulo_replication_source_relationship path attributes now correctly trigger replacement when changed.
• qumulo_snapshot_policy validators no longer reject unknown values during plan, fixing errors when attributes reference other resources.
• qumulo_filesystem_baremetal and qumulo_filesystem_edge_baremetal now emit a diagnostic warning when all cluster nodes are degraded.
• qumulo_role Delete now handles 404 gracefully instead of returning an error.
• qumulo_smb_share Delete now handles 404 gracefully.
• qumulo_active_directory now correctly force-leaves the domain when credentials are empty.
• Error diagnostics now propagate correctly in qumulo_nfs_export, qumulo_ftp_settings, qumulo_s3_access_key, qumulo_s3_bucket, qumulo_smb_settings, qumulo_ldap_settings, and qumulo_filesystem_azure.

1.1.0 - 2026-03-14

Added

• qumulo_filesystem_baremetal resource for deploying Qumulo clusters on bare metal nodes. Supports cluster creation and node-add scaling.
• qumulo_filesystem_edge_baremetal resource for single-node bare metal edge clusters.
• cluster_version defaults to the latest available version when omitted in bare metal resources.
• Deployment name length validation at plan time, preventing creation failures from storage-side limits.

1.0.33 - 2026-03-08

Fixed

• qumulo_replication_source_relationship no longer panics when snapshot policy attributes are missing or nil. Unsafe type assertions replaced with safe helpers.
• qumulo_replication_source_relationship now surfaces errors from blackout window and snapshot policy state conversion instead of silently propagating bad state.
• qumulo_portal and qumulo_portal_spoke now surface errors from host list conversion instead of silently producing empty or unknown values.

1.0.32 - 2026-03-06

Added

• networking_mode attribute is now populated during import of legacy azure-terraform-cnq clusters, enabling accurate state representation for clusters using Qumulo-managed networking.

Fixed

• Scaling operations on imported azure-terraform-cnq clusters no longer hang indefinitely. These clusters have local authentication disabled on their App Configuration store, which caused the provider's status polling to fail with 409 Conflict. The provider now automatically re-enables local auth when it encounters this condition.
• Provisioner OS disk is no longer orphaned after terraform destroy. Azure may take several seconds to detach the disk from a deleted VM; the provider now retries disk deletion with backoff instead of silently giving up on the first failure.
• Provisioner wait loop no longer has an artificial boot-check limit that could cause premature timeout on slow-booting clusters.
• VM name lookups for legacy azure-terraform-cnq clusters with mixed-case deployment names now work correctly. Previously, case-sensitive prefix matching could fail to find existing cluster VMs.

1.0.31 - 2026-03-05

Fixed

• terraform destroy now cleans up OS disks on clusters deployed by the Azure marketplace or older provisioning tools. These clusters use different disk naming conventions ({vm}-disk1 instead of {vm}-osdisk), which caused the provider to skip disk deletion and leave orphaned, billable managed disks in Azure.

1.0.30 - 2026-03-05

Fixed

• terraform destroy on legacy azure-terraform-cnq clusters now deletes storage accounts, KeyVault, and storage/KeyVault private endpoints from the persistent storage resource group. Previously, these resources were looked up in the cluster resource group, causing deletions to fail silently and leaving billable resources orphaned in Azure.

1.0.29 - 2026-03-05

Fixed

• Tag updates on legacy azure-terraform-cnq clusters now apply tags to storage and KeyVault private endpoints in the correct resource group. Previously, these endpoints were looked up in the cluster resource group instead of the persistent storage resource group, so tags were silently not applied.

1.0.28 - 2026-03-05

Fixed

• Capacity scaling (soft_capacity_limit_tb increase) on legacy azure-terraform-cnq clusters now generates correct storage account URIs. Previously, the provisioner received URIs using the cluster deployment name instead of the storage resource group name as the naming prefix, causing the capacity clamp to fail.

1.0.27 - 2026-03-05

Fixed

• terraform destroy for qumulo_filesystem_azure now surfaces errors from public IP and storage account cleanup instead of silently reporting success while leaving orphaned, billable resources in Azure.

1.0.26 - 2026-03-03

Added

• New persistent_storage_resource_group attribute on qumulo_filesystem_azure for importing legacy clusters created with the azure-terraform-cnq module, where persistent storage lives in a separate resource group from the cluster VMs.
• vm_type is now read from Azure during terraform import, so the imported state matches the actual VM size without requiring manual configuration.

Changed

• The provisioner now receives the admin password directly from the Terraform configuration instead of fetching it from Key Vault at runtime. This removes the Key Vault dependency from all provisioner operations (scale-up, replacement, storage updates).

Fixed

• terraform import for qumulo_filesystem_azure no longer triggers a destroy/recreate cycle. Previously, name, location, and subnet_id were not populated during import, causing Terraform to plan a replacement.
• cluster_version validation no longer fails during import when the running version is not in the package registry.
• qumulo_snapshot_policy updates now send only the schedule fields relevant to the configured frequency, preventing API errors from extraneous fields.
• qumulo_s3_bucket no longer reports inconsistent results after apply for lock_config and versioning attributes.
• qumulo_s3_access_key no longer reports inconsistent results after apply for the user.sid attribute.
• terraform destroy for qumulo_filesystem_azure now surfaces errors from NIC and disk cleanup instead of silently ignoring failures.
• terraform destroy now cleans up partially-created infrastructure when the deployment preparation phase fails mid-way.

1.0.25 - 2026-03-02

Fixed

• terraform destroy for qumulo_filesystem_azure now cleans up the provisioner VM and its associated NIC and OS disk, preventing orphaned resources and unblocking NSG deletion.
• terraform destroy no longer fails to delete the App Configuration store (previously failed with "parameter configStoreName cannot be empty" due to an uninitialized deployment name).
• terraform destroy now deletes cluster VMs in parallel instead of sequentially, reducing VM cleanup time from ~12 minutes to ~5 minutes for a 3-node cluster.
• Key Vault and App Configuration soft-delete purge operations no longer block terraform destroy for ~10 minutes each. Purge is now initiated asynchronously (Azure completes it in the background).

1.0.24 - 2026-02-28

Fixed

• terraform destroy for qumulo_filesystem_azure now reports errors when Azure resources fail to delete, preventing Terraform from dropping state while billable resources remain.
• qumulo_filesystem_azure creation now cleans up partially-created Azure resources (VMs, storage accounts, Key Vault, etc.) when provisioning fails mid-deployment.
• terraform import for qumulo_local_user and qumulo_local_group now works correctly (previously failed with an empty ID on the post-import read).
• S3 bucket policy operations (qumulo_s3_bucket_policy) now retry on transient errors and automatically re-authenticate on token expiry, matching the behavior of all other API operations.
• NFS export updates now correctly sync restriction changes from the API response, preventing state drift after modifying restrictions.
• Provisioner VM debug logs no longer include the decoded user-data script content, which could contain credentials.
• Concurrent Terraform operations no longer cause redundant login requests to the same cluster.

1.0.23 - 2026-02-28

Added

• Import support for legacy Qumulo clusters (clusters not originally created by this provider).
• Private DNS zones for App Configuration, Storage, and Key Vault endpoints.
• SSH public key propagation to new VMs during scale-up and replacement operations.
• Automatic cluster version detection during scale-up and replacement.

Changed

• Admin password is now read from Terraform state instead of Key Vault during cluster operations, removing the Key Vault dependency for day-2 operations.
• VM naming validation relaxed to allow numeric suffixes in existing deployments.

Fixed

• Application Security Group name mismatch during cluster deletion.
• Node ID extraction now works correctly after importing existing clusters.

1.0.22 - 2026-02-27

Added

• Host-managed networking for Azure deployments.

Fixed

• Scaling operations no longer produce unexpected diffs on internal_state.
• Retry deployments no longer fail due to App Configuration or Key Vault soft-delete conflicts.
• Intermediate state is now persisted during multi-step Azure filesystem updates, preventing state loss if interrupted.
• Improved error messages when Azure deployment is interrupted mid-operation.
• Cluster node provisioning no longer fails on Debian due to missing package dependencies.

1.0.21 - 2026-02-20

Breaking

• Azure provider configuration has moved into a nested azure {} block. subscription_id and azure_environment are no longer top-level provider attributes.

Upgrade notes: Update your provider block:

# Before (1.0.20 and earlier)
provider "qumulo" {
  subscription_id   = "..."
  azure_environment = "public"
}

# After (1.0.21+)
provider "qumulo" {
  azure {
    subscription_id = "..."
    environment     = "public"   # renamed from azure_environment
  }
}

1.0.20 - 2026-02-19

Added

• qumulo_portal now supports multiple network addresses via the addresses attribute.

1.0.19 - 2026-02-19

Fixed

• Portal hub accept requests now correctly send an empty authorized_roots array when no roots are specified.

1.0.18 - 2026-02-19

Fixed

• Portal cleanup no longer fails when a spoke UUID lookup encounters a transient error.

1.0.17 - 2026-02-19

Fixed

• Portal hub accept payload is now correct when authorized_roots is unset.

1.0.16 - 2026-02-19

Added

• qumulo_portal resource for creating and managing Cloud Data Fabric portals.
• qumulo_portal_root resource for managing portal root directories.

1.0.15 - 2026-02-19

Added

• qumulo_portal_hub_root resource for authorizing root directories on hub portals.

1.0.14 - 2026-02-18

Fixed

• Spoke root creation now retries on transient connection errors during portal setup, improving reliability of multi-cluster deployments.

1.0.13 - 2026-02-18

Changed

• Default portal port changed to 3713 to match Qumulo cluster defaults.

Removed

• Portal status field removed from schema (read-only server state).

Fixed

• Portal Update operation now works correctly.

1.0.12 - 2026-02-18

Changed

• Portal resources migrated to v2 API with multi-root support. Each portal can now authorize multiple root directories.

1.0.11 - 2026-02-04

Fixed

• qumulo_filesystem_azure now uses the configured provisioner_vm_type instead of a hardcoded Standard_B2s.

1.0.10 - 2026-02-04

Fixed

• endpoint_ips is now always set to known cluster IP addresses after apply, preventing unnecessary diffs on subsequent plans.

1.0.9 - 2026-02-03

Fixed

• v4 series VMs now correctly report zero temporary disks, preventing deployment failures on L2s_v4 and L2as_v4.

1.0.8 - 2026-02-03

Fixed

• Block device count calculation corrected for all VM types, preventing disk attachment failures.

1.0.7 - 2026-02-03

Fixed

• v4 series VMs now use Gen2 images as required by Azure.

1.0.6 - 2026-02-03

Fixed

• VM type validation rejects unsupported types at plan time instead of failing during apply.

1.0.5 - 2026-02-03

No customer-facing changes (test updates only).

1.0.4 - 2026-02-03

Added

• L2s_v4 and L2as_v4 VM type support. Deploy Qumulo clusters on Azure Lsv4 and Lasv4 series instances with NVMe-based local storage.

1.0.3 - 2026-02-01

Initial release of the Qumulo Terraform Provider with 33 resources across two categories: Azure infrastructure management and cluster API configuration.

Provider

• Connection profiles for centralized cluster authentication. Define credentials once in the provider block and reference by name in each resource.
• Multi-cluster management via for_each with named profiles for fleet-wide configuration.
• TLS support with insecure_skip_verify and ca_certificate options.
• subscription_id is optional when managing cluster-only resources.

Azure Infrastructure (qumulo_filesystem_azure)

• Full cluster lifecycle: create, scale (up/down), replace, and destroy.
• Parallel VM deployment for faster provisioning.
• Automatic resource group creation.
• Private endpoints for storage accounts and Key Vault.
• Cross-subscription managed identities and private DNS zones.
• Storage expansion via soft_capacity_limit_tb.
• Custom VM images and Azure Marketplace images.
• Azure Government and Azure Germany cloud support.
• Floating IPs for Qumulo DNS.
• Tag propagation to all Azure resources.
• Import support for existing deployments.

Cluster Management Resources

• Storage protocols: NFS exports and settings, SMB shares and settings, FTP settings, S3 buckets/keys/policies/settings.
• Cloud Data Fabric: Portal spoke and hub resources with root directory management.
• Identity and access: Active Directory, LDAP, SAML SSO, local users/groups/members, RBAC roles/members.
• Cluster configuration: Cluster settings, SSL certificates, time configuration, file system settings, web UI settings.
• Data management: Directory quotas, snapshot policies, replication (source/target/object relationships).
• Audit and logging: Syslog and CloudWatch resources.

See resource documentation for the full list and configuration details.