I am importing all Azure Front Door related resources and after importing Front Door WAF and Security policy, I am saying force replacement due to change - frontDoorWebApplicationFirewallPolicies to frontdoorWebApplicationFirewallPolicies and resourceGroups to resourcegroups
Note : firewall policy id is not passed via variable and is referred cdn_frontdoor_firewall_policy_id = azurerm_cdn_frontdoor_firewall_policy.rs_azurerm_cdn_frontdoor_firewall_policy[0].id I have imported first WAF and than Front Door Security Policy.
Following is the TF Plan generated after import -
module.rsm_azure_frontdoor.azurerm_cdn_frontdoor_security_policy.rs_azurerm_cdn_frontdoor_security_policy[0] must be replaced
-/+ resource "azurerm_cdn_frontdoor_security_policy" "rs_azurerm_cdn_frontdoor_security_policy" {
~ id = "/subscriptions/******/resourceGroups/*****/providers/Microsoft.Cdn/profiles/frontdoor-profile/securityPolicies/securitypolicy398439482" -> (known after apply)
name = "securitypolicy398439482"
# (1 unchanged attribute hidden)
~ security_policies {
~ firewall {
~ cdn_frontdoor_firewall_policy_id = "/subscriptions/********/resourceGroups/*****/providers/Microsoft.Network/frontdoorWebApplicationFirewallPolicies/wafirewall304873483" -> "/subscriptions/******/resourceGroups/*****/providers/Microsoft.Network/frontDoorWebApplicationFirewallPolicies/wafirewall304873483" # forces replacement
~ association {
# (1 unchanged attribute hidden)
~ domain {
~ active = true -> (known after apply)
~ cdn_frontdoor_domain_id = "/subscriptions/******/resourcegroups/*****/providers/Microsoft.Cdn/profiles/frontdoor-profile/customdomains/nameofdomain" -> "/subscriptions/******/resourceGroups/*****/providers/Microsoft.Cdn/profiles/frontdoor-profile/customDomains/nameofdomain" # forces replacement
}
}
}
}
Kindly let me know how to avoid this force replacement. What might be the cause for it ? I have also observed force replacement because of change in resourceGroups to resourcegroups for few other Azure resources as well after importing. Azurerm version : 3.50.0
Expected TF Plan output No changes. Your infrastructure matches the configuration.
One of the responsibilities of a provider in Terraform's architecture is to implement logic that takes each difference between the prior state and the configuration, and decides whether that difference represents a meaningful change (the configuration now says something different) or just a different way to write the same information.
In this case it seems like either the remote API is case-sensitive or the
hashicorp/azurermprovider has a bug where it's incorrectly classifying this difference as a meaningful change rather than just a different way to write the same value.Regardless of whether or not it is a provider bug, the main way for you to avoid it would be to change your configuration to match the value as currently tracked in the remote API, using exactly the same case for all of the characters.
If you think that the provider is behaving incorrectly in this case because you know that this value is treated as case-insensitive by the remote API then you could additionally report a bug in the provider's GitHub repository, and then hopefully the provider maintainers can add a suitable rule to a future version of the provider so that it will treat this argument as case-insensitive.