-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Description
Is there an existing issue for this?
- I have searched the existing issues
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.
Terraform Version
1.3.9
AzureRM Provider Version
4.3.0
Affected Resource(s)/Data Source(s)
all resources
Terraform Configuration Files
N/ADebug Output/Panic Output
N/AExpected Behaviour
Expected Behavior:
terraform destroy should successfully remove the deployed Azure resources, with the standard metadata_host configured; with or without a trailing slash added to the resource managerendpoint. The provider should handle the trailing slash gracefully.
Actual Behaviour
terraform destroy fails with an error similar to (exact error message may vary depending on the specific API call failing, but the root cause is the malformed URL, specific error described above). The terraform destroy will fail to update state and let terraform know the destroy occurred and as a result retries to delete the resources on a loop:
Steps to Reproduce
Reproduction Steps:
Configure AzureRM Provider: Ensure your provider "azurerm" block explicitly sets the resource manager endpoint metadata_host with what is provided for that environment (management.azure.com).
For example:
Terraform
provider "azurerm" {
features {}
# ... other configuration ...
metadata_host = "management.azure.com" # Must be the standard endpoint for that environment (gov or public)
}
Deploy Resources: Create a main.tf (or similar) with any Azure resource. For demonstration, a simple resource group is sufficient:
Terraform
resource "azurerm_resource_group" "example" {
name = "my-resource-group-to-destroy"
location = "East US"
}
Initialize and Apply:
Bash
terraform init
terraform apply --auto-approve
Attempt Destroy:
Bash
terraform destroy --auto-approve
Expected Behavior:
terraform destroy should successfully remove the deployed Azure resources, with the standard metadata_host configured; with or without a trailing slash added to the resource managerendpoint. The provider should handle the trailing slash gracefully.
Important Factoids
No response
References
Labels: bug, azurerm provider, terraform destroy
Environment:
Terraform Version: v1.3.9, v1.12
AzureRM Provider Version: (4.3.0 - 4.30)
Operating System: (Ubuntu 20.04.6)
Cloud: Azure Public Cloud
TLDR;
We are requesting that the ResourceManager entry to be sanitized to be without the trailing /. Values from management.azure.com and from govcloud - e.g."resourceManager": "https://management.azure.com/
"resourceManager": "https://management.usgovcloudapi.net",
This is in Public cloud has a trailing /, but not gov cloud does not. This only impacts the provider if you are using the metadata_host parameter. Hypothesis is that the api endpoints is a concatenation of the resource manger endpoint and the API path resulting in APIs calls with // like https://management.azure.com//subscription/subscription-id/resourcegroup/resourcegroupid/resourcetype.
When a delete is issued, the provider breaks down the URI into key value pairs based on the slash and that results in the pairs being "": subscription, subscription_id: resouce:group, resource_group_id: resource_type which is reconstituted to///subscription/subscription_id/resource_group/resource_group_id/resource_type.
When a GET is performed against that url, it always returns a 200 and the list of resources of that type. Because the wrong URL is being watched, it will never return a 404 and TF will eventually timeout.
Description:
When attempting to run terraform destroy with the azurerm provider, the operation consistently fails. After investigation, it appears the provider is incorrectly parsing one of the key value pairs from is returned by the provided metadata_host because of how it parses a value (resource manager) that contains a trailing slash, leading to malformed API requests during the destroy process.
Reproduction Steps:
Configure AzureRM Provider: Ensure your provider "azurerm" block explicitly sets the resource manager endpoint metadata_host with what is provided for that environment (management.azure.com).
For example:
Terraform
provider "azurerm" {
features {}
# ... other configuration ...
metadata_host = "management.azure.com" # Must be the standard endpoint for that environment (gov or public)
}
Deploy Resources: Create a main.tf (or similar) with any Azure resource. For demonstration, a simple resource group is sufficient:
Terraform
resource "azurerm_resource_group" "example" {
name = "my-resource-group-to-destroy"
location = "East US"
}
Initialize and Apply:
Bash
terraform init
terraform apply --auto-approve
Attempt Destroy:
Bash
terraform destroy --auto-approve
Expected Behavior:
terraform destroy should successfully remove the deployed Azure resources, with the standard metadata_host configured; with or without a trailing slash added to the resource managerendpoint. The provider should handle the trailing slash gracefully.
Actual Behavior:
terraform destroy fails with an error similar to (exact error message may vary depending on the specific API call failing, but the root cause is the malformed URL, specific error described above). The terraform destroy will fail to update state and let terraform know the destroy occurred and as a result retries to delete the resources on a loop:
Error: ...
Potential Cause (Hypothesis):
It appears the azurerm provider's internal URL construction logic might be concatenating the metadata_host with resource-specific paths without correctly normalizing or stripping potential trailing slashes from the base endpoint, leading to double slashes in the final API request URL (e.g., https://management.azure.com//subscriptions/...).
Workaround (if applicable):
Currently, the only known workaround is to remove the trailing slash from the ResourceManager in the response from the metadata_host in the provider configuration when mocking the metadata endpoint:
Bash
// Mock the response from the metadata_host using a custom metadata_host
// Set the resource manager api endpoint within the mock data so as to resolve the conflict from the lack of correct parsing.
While this allows terraform destroy to succeed, it should not be necessary and indicates a bug in the provider's URL handling.
Request:
Please investigate and fix the parsing of themetadata_host response to correctly handle trailing slashes, ensuring terraform destroy operates reliably regardless of this configuration detail.