egorshulga
commented
1 year ago While testing on another environment I also spotted another resources that do not settle after terraform apply:
# azurerm_mssql_server_extended_auditing_policy.auditingSettings must be replaced
-/+ resource "azurerm_mssql_server_extended_auditing_policy" "auditingSettings" {
~ id = "/subscriptions/.../resourceGroups/ResourceGroup/providers/Microsoft.Sql/servers/sql-server/extendedAuditingSettings/Default" -> (known after apply)
~ server_id = "/subscriptions/.../resourceGroups/Resourcegroup/providers/Microsoft.Sql/servers/sql-server" -> "/subscriptions/.../resourceGroups/ResourceGroup/providers/Microsoft.Sql/servers/sql-server" # forces replacement
# (5 unchanged attributes hidden)
}
# module.houseProd.azurerm_linux_web_app.app_service will be updated in-place
~ resource "azurerm_linux_web_app" "app_service" {
id = "/subscriptions/.../resourceGroups/ResourceGroup/providers/Microsoft.Web/sites/app-service"
name = "app-service"
~ service_plan_id = "/subscriptions/.../resourceGroups/Resourcegroup/providers/Microsoft.Web/serverfarms/app-service-plan" -> "/subscriptions/.../resourceGroups/ResourceGroup/providers/Microsoft.Web/serverfarms/app-service-plan"
tags = {}
# (18 unchanged attributes hidden)
# (3 unchanged blocks hidden)
}
ADBjester
eehret
DhanushBL
PrakashRajanSakthivel
Is there an existing issue for this?
Community Note
Terraform Version
1.4.2
AzureRM Provider Version
3.47.0
Affected Resource(s)/Data Source(s)
azurerm_data_protection_backup_instance_blob_storage, azurerm_mssql_server_microsoft_support_auditing_policy
Terraform Configuration Files
(Related to existing resources, see description below)
Debug Output/Panic Output
Expected Behaviour
Terraform Plan should settle down. After running
terraform applysubsequent calls toterraform planshould not show any differences.Actual Behaviour
Terraform Plan does not settle down. Terraform detects some differences. For
azurerm_data_protection_backup_instance_blob_storageit is just an update operation, forazurerm_mssql_server_microsoft_support_auditing_policyit is even worse – it is a re-create operation.Steps to Reproduce
We are migrating from a really large and long-lived ARM template to terraform. We already have 5 environments that we must not re-create (this includes the Prod environment). We have ~200 resources in a NonProd environments and ~240 resources in Prod environments.
Initially, when we implemented the Terraform code and imported all of the resources into state, there were ~200 (effectively all of them) that Terraform wanted to re-create. We analyzed the reason, and we found that it is the Resource Group name which is causing this. It seems it is a well-known issue, that's been reported multiple times, that Azure almost for all of the resources is case-insensitive, while AzureRM is by default case-sensitive. The name of Resource Groups appears in IDs of resources, and a lot of resources simply parse the ID to get the name of their Resource Groups. Additionally, Resource Group names are not consistently stored across different resources in Azure (the best example would be LogAnalytics, which stores the name of its Resource Group lowercased – we observed it across different subscriptions, so we'd assume that this would be true for everyone using Azure).
We found a workaround of manipulating Resource IDs by fixing their Resource Group names on-the-fly while performing initial import. This reduced the amount of operations to ~60 updates (there are still some properties stored on the Azure side which have inconsistent casing) and ~80 re-creations (some of inconsistent properties stored on the Azure side can't be updated without resources re-creation). Luckily among the re-created resources there were none that we can't re-create (so, we are taking the risk of increased downtime during deployment to Prod, and this includes re-creation of these resources: WebTests, ActionGroups, Alerts, RoleAssignments, NGS Associations).
Unfortunately, even after applying workarounds and re-creating resources, we still observe unsettled Terraform Plan. We suspect it is Azure who is (a) refusing to update some properties if they differ only in casing and (b) decides on casing of RG's names for us, so neither we nor AzureRM provider running infrastructure provisioning for us can influence this.
In one of the previous issues I've seen a remark, that we can't easily decide on case-sensitivity, and we should be absolutely sure that this is how Azure behaves (and so it does not introduce issues for thousands of developers). I would like to leave this link to documentation: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules
If you would allow me, I would like to ask these questions (and use them to start a discussion):
(1) What is your view on the casing issues in general?
It seems that when AzureRM and Terraform is used from the very beginning of life of a Resource Group, then handling is much better. Numerous issues arise only when we migrate long-living existing infrastructure.
(2) It seems to be a tremendous amount of work required to identify all case-insensitive properties and make them like that. Although I spotted that some of the properties already use
DiffSuppressFunc: suppress.CaseDifference, so I would assume that this work is already in progress. Would you have a plan to tackle all of the casing issues, or do you prefer going on case-by-case basis?(3) Would you kindly accept contributions to make properties, that are making troubles for us, case-insensitive?
Important Factoids
No response
References
No response