azurerm_netapp_volume - support for the breakthrough_mode_enabled property and netapp API version bump to 2026-05-01 - #33215
Open
paulomarquesc wants to merge 9 commits into
Conversation
…ough Mode volumes
The earlier API version bump commit updated vendor/modules.txt to reference netapp/2026-05-01 but the generated vendor directory itself was never staged, while the superseded 2026-01-01 packages remained committed. This left the branch unbuildable, as the provider imports netapp/2026-05-01/... which was absent from the vendored tree. Generated with `go mod vendor`; no vendored file was edited by hand. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: ec2e1e94-684b-4751-8ac4-2511591992d2
paulomarquesc
requested review from
a team,
WodansSon and
magodo
as code owners
August 25, 2026 20:50
Volumes created from a snapshot must use the same network features as the source volume, otherwise the service rejects the create with SnapshotVolumeNetworkFeaturesConflictWithNewVolume. The snapshot, nfsv3FromSnapshot and shortTermClone configurations omitted network_features on both the source and the restored volume, leaving the value up to the service default. Because the default is applied independently for a new volume and for a snapshot restore, the source could land on Standard while the restored volume was created as Basic, failing the test. Pin both sides of each pair to Standard so the configurations no longer depend on service side defaults. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: ec2e1e94-684b-4751-8ac4-2511591992d2
…plication The crossZoneRegionReplication configuration creates two data protection destination volumes, test_cross_zone and test_cross_region, that both replicate from test_primary. Neither depends on the other, so Terraform creates them concurrently and the service rejects the second one with FileSystemAllocationFailed, "Another volume creation is in progress". crossZoneReplication and crossRegionReplication only create a single destination volume each and are already serialized by their dependency on the source volume, which is why they are not affected. Make test_cross_region depend on test_cross_zone so the two replication relationships are established one after the other. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: ec2e1e94-684b-4751-8ac4-2511591992d2
This comment has been minimized.
This comment has been minimized.
Contributor
Author
Posting summary of tests and details.Rerun of the failed ones (the persistent ones are an issue with my sub) |
Collaborator
|
@paulomarquesc - One or more tests failed in this PR. Please review the failures. Total: 116 Test Details
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Community Note
Description
This PR adds support for Azure NetApp Files Breakthrough Mode on large volumes, exposed as a new
breakthrough_mode_enabledproperty on theazurerm_netapp_volumeresource and data source.Breakthrough Mode places a large volume on dedicated capacity, which delivers consistently higher throughput and allows the volume to grow well beyond the standard large volume ceiling (up to 2,400 TiB). The feature is opt-in and requires the subscription to be onboarded to the
ANFBreakthroughModeandANFLargeVolumesfeatures, and is only available in regions where dedicated capacity has been provisioned.API version bump
breakthroughModeis only present in the NetApp2026-05-01API version, so this PR also bumps the NetApp service from2026-01-01to2026-05-01. The delta between the two versions is purely additive — the only change is the newbreakthroughModeproperty onvolumeProperties(present in thevolumes,volumegroupsandsnapshotpoliciespackages). No existing type, field or method signature changed, so the bump carries no behavioural risk for existing resources.2026-05-01was already available in Pandora and in thego-azure-sdkversion already pinned ingo.mod(v0.20260811.1225050), so no dependency version change was required — onlygo mod vendor. No vendored file was edited by hand.Behaviour
breakthrough_mode_enabledisForceNew. The service does not allow a volume to move between single-LIF and multi-LIF configurations, andbreakthroughModeis not present on the PATCH model (VolumePatchProperties), so the property cannot be updated in place.true. When it isfalsethe property is omitted entirely rather than sent asDisabled, so subscriptions that are not onboarded to the feature are unaffected by this change.nulland aDisabledresponse map tofalse, so existing volumes and volumes created before this change produce no diff.Validation
storage_quota_in_gbpreviously validated to a maximum of1048576(1 PiB). Breakthrough Mode volumes may be sized up to 2,400 TiB, so the schema-level maximum has been raised to2457600and the per-flavour limits are now enforced inCustomizeDiff:Note that a Breakthrough Mode volume has a lower minimum than a standard large volume, which is why the breakthrough branch is evaluated first.
Two further validations are applied:
breakthrough_mode_enabledrequireslarge_volume_enabledto betrue.cool_accesscannot be configured at the same time a Breakthrough Mode volume is created. Per the service behaviour this restriction applies to create only — cool access may be enabled on a subsequent update — so the check is scoped to create by testing for an empty resource ID inCustomizeDiff.PR Checklist
For example: “
resource_name_here- description of change e.g. adding propertynew_property_name_here”Changes to existing Resource / Data Source
Testing
New acceptance tests on
azurerm_netapp_volume:TestAccNetAppVolume_breakthroughModeTestAccNetAppVolume_breakthroughModeUpdateSizeTestAccNetAppVolume_breakthroughModeRequiresLargeVolumelarge_volume_enabledisfalseTestAccNetAppVolume_breakthroughModeConflictsWithCoolAccesscool_accessis configured at create timeTestAccNetAppVolume_breakthroughModeBelowMinimumSizeTestAccDataSourceNetAppVolume_breakthroughModeThe three negative tests use
PlanOnlyso they validateCustomizeDiffwithout provisioning anything.Because dedicated capacity is only available in specific regions, the Breakthrough Mode tests use their own capacity pool templates pinned to
swedencentralviagetBreakthroughModeTestLocation(), rather than thewestus2/eastus2pair used by the remaining NetApp volume tests.The wider NetApp suite can be exercised to confirm the
2026-05-01bump does not regress existing resources, excluding the Breakthrough Mode, Oracle and SAP HANA volume group tests which require dedicated capacity that is not consistently available in the test subscriptions:Change Log
Below please provide what should go into the changelog (if anything) conforming to the Changelog Format documented here.
netapp- update to API version2026-05-01[GH-00000]azurerm_netapp_volume- support for thebreakthrough_mode_enabledproperty [GH-00000]This is a (please select all that apply):
Related Issue(s)
N/A
AI Assistance Disclosure
GitHub Copilot CLI was used to assist with this contribution, covering the API version bump, the schema and CRUD wiring, the acceptance tests, the documentation updates and the example configuration. All changes were reviewed, built, linted and acceptance-tested by the author before submission.
Rollback Plan
If a change needs to be reverted, we will publish an updated version of the provider.
Changes to Security Controls
There are no changes to security controls in this pull request. The new property selects a capacity placement mode for the volume and does not alter access controls, encryption or logging behaviour.