Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question/Feedback]: "Unexpected API Version Change Detected in Terraform Plan for Subnet, vnet and peering Resources" #193

Open
1 task done
Vinaum8 opened this issue Jan 22, 2025 · 3 comments
Labels
Language: Terraform 🌐 This is related to the Terraform IaC language Needs: Immediate Attention ‼️ Immediate attention of module owner / AVM team is needed Needs: Triage 🔍 Maintainers need to triage still Status: Response Overdue 🚩 When an issue/PR has not been responded to for X amount of days Type: Question/Feedback 🙋 Further information is requested or just some feedback

Comments

@Vinaum8
Copy link

Vinaum8 commented Jan 22, 2025

Check for previous/existing GitHub issues

  • I have checked for previous/existing GitHub issues

Description

While running terraform plan using the AzureRM provider, Terraform detects changes in the type and output attributes of a subnet, vnet and peering resources.

The detected change involves an API version update for the resource type and marks the output as (known after apply).
However, the plan does not indicate resource recreation.

Observed Behavior:

~ output = {
  - id         = "/subscriptions/**_subscription_ID_**/resourceGroups/DataWarehouse/providers/Microsoft.Network/virtualNetworks/**_vnet_name_**/subnets/**_subnet_name_**"
  - properties = {
      - ipConfigurations  = [
          - {},
        ]
      - provisioningState = "Succeeded"
    }
  - type       = "Microsoft.Network/virtualNetworks/subnets"
} -> (known after apply)

~ type = "Microsoft.Network/virtualNetworks/subnets@2024-05-01" -> "Microsoft.Network/virtualNetworks/subnets@2023-11-01"

Plan Summary:
Plan: 0 to add, 3 to change, 0 to destroy.

Expected Behavior:
When running terraform plan after importing resources that are already fully configured in the cloud (e.g., subnets and peering), Terraform should report no changes. The expected output should indicate that the infrastructure is fully in sync, such as:

Plan: 0 to add, 0 to change, 0 to destroy.

This behavior is critical because the resources are already provisioned and functioning correctly, and no further modifications are required. Any detected changes should only appear if there is a material difference between the Terraform configuration and the actual state of the resources in the cloud.

Environment:

Terraform Version: 1.10.4
AzureRM Provider version = "3.116.0"
Affected Resource: azurerm_subnet, vnet, peering.

Additional Context:

I reviewed the AzureRM 4.0 Upgrade Guide and did not find any recommendations or guidance regarding this behavior or the persistent API version updates in the type attribute.

@Vinaum8 Vinaum8 added Language: Terraform 🌐 This is related to the Terraform IaC language Needs: Triage 🔍 Maintainers need to triage still Type: Question/Feedback 🙋 Further information is requested or just some feedback labels Jan 22, 2025

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-terraform) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

  • To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
  • To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

@microsoft-github-policy-service microsoft-github-policy-service bot added the Status: Response Overdue 🚩 When an issue/PR has not been responded to for X amount of days label Jan 28, 2025

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-terraform) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

  • To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
  • To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-terraform) immediate attention as it hasn't been responded to within 6 business days. **

Tip

  • To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
  • Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.

@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs: Immediate Attention ‼️ Immediate attention of module owner / AVM team is needed label Feb 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Language: Terraform 🌐 This is related to the Terraform IaC language Needs: Immediate Attention ‼️ Immediate attention of module owner / AVM team is needed Needs: Triage 🔍 Maintainers need to triage still Status: Response Overdue 🚩 When an issue/PR has not been responded to for X amount of days Type: Question/Feedback 🙋 Further information is requested or just some feedback
Projects
None yet
Development

No branches or pull requests

1 participant