Case sensitive bug with "azurerm_cdn_frontdoor_*" ("resourceGroups" vs "resourcegroups")

[joakimlemb]

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 "+1" or "me too" comments, 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.4.2

AzureRM Provider Version

3.83.0

Affected Resource(s)/Data Source(s)

azurerm_cdn_frontdoor_origin_group
azurerm_cdn_frontdoor_origin
azurerm_cdn_frontdoor_route
azurerm_cdn_frontdoor_custom_domain
azurerm_cdn_frontdoor_custom_domain_association
azurerm_cdn_frontdoor_endpoint
azurerm_cdn_frontdoor_* (assuming this is affecting all azurerm_cdn_frontdoor_* resource types)

Terraform Configuration Files

resource "azurerm_cdn_frontdoor_profile" "example" {
  name                     = "example-afd"
  resource_group_name      = azurerm_resource_group.example.name
  sku_name                 = "Standard_AzureFrontDoor"
}

resource "azurerm_cdn_frontdoor_endpoint" "example" {
  name                     = "example-fde"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.example.id
}

Debug Output/Panic Output

"resourceGroups" vs "resourcegroups" case sensitive issue.

Expected Behaviour

Nothing.

Actual Behaviour

Terraform will perform the following actions:

  # azurerm_cdn_frontdoor_endpoint.example must be replaced
-/+ resource "azurerm_cdn_frontdoor_endpoint" "example" {
      ~ cdn_frontdoor_profile_id = "/subscriptions/REDACTED/resourceGroups/example-rg/providers/Microsoft.Cdn/profiles/example-afd" -> "/subscriptions/REDACTED/resourcegroups/example-rg/providers/Microsoft.Cdn/profiles/example-afd" # forces replacement
    }

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

Steps to Reproduce

terraform plan

Important Factoids

https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules

References

Similar bugs:
#24138
#23990
#17090
#24123
#24109

[WodansSon]

Hi @joakimlemb, this is currently by design(see @tombuildsstuff's comment on PR #22289) and as such I will be closing this issue as by design. However, I will leave this issue open until Friday (12/15/2023) incase there was something I did not understand in the repro case.

[tombuildsstuff]

@joakimlemb whilst what @WodansSon has mentioned is correct (this is expected/by design) - it's worth noting that this diff is coming from the azurerm_cdn_frontdoor_profile resource, where it appears to have been imported using a Resource ID format differing what from what's defined in the import section of the documentation.

As such, you should be able to workaround this issue by removing this resource from your Terraform State and re-importing it using the Resource ID format defined in the import section of the documentation - namely updating the resourcegroups key to be resourceGroups e.g.

terraform state rm azurerm_cdn_frontdoor_profile.example
terraform import azurerm_cdn_frontdoor_profile.example /subscriptions/REDACTED/resourceGroups/example-rg/providers/Microsoft.Cdn/profiles/example-afd

In the future when the CDN resources are migrated to using hashicorp/go-azure-sdk the updated Resource ID parsers/validators have additional validation to check the casing on the resourceGroups segment matches during both terraform import (to handle new resources) and terraform plan (to validate any resources which have previously been imported incorrectly) - but in the interim it should be possible to workaround this by following the process outlined above.

Thanks!

[joakimlemb]

@tombuildsstuff
Thanks, this workaround works for now, but if azurerm will start validating the case again after import it would probably start wanting to replace that resource again since it is the azure api that returns the resource id with lowercase "resourcegroups":

From the resource browser at https://resources.azure.com/

Is it a good idea to care about case sensitivity for this when the azure docs states the opposite?
From: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules
"Always perform a case-insensitive comparison of names."

[tombuildsstuff]

@joakimlemb

[..] if azurerm will start validating the case again after import it would probably start wanting to replace that resource again since it is the azure api that returns the resource id with lowercase "resourcegroups"

We don't parse that value from the Azure API response - since this resource is nested under the CDN Profile, it's defined within the Provider (else it'd 404 when we retrieve it). Where values are parsed from the Azure API response (e.g. the Network Interface ID for a Virtual Machine) should the Resource ID be returned miscased (as in your screenshot above) we'd parse the Resource ID case-insensitively and re-case the key components as required - handling resourcegroups and networkinterfaces becoming resourceGroups and networkInterfaces, respectively.

"Always perform a case-insensitive comparison of names."

Having chatted extensively with the ARM Team about this unfortunately that document is outdated (there's been multiple differing sets of guidance over the years) - however Azure API's are supposed to be case insensitive in Requests for both URIs and Enums - and case-insensitive in Responses - however different APIs implement this behaviour differently (due to said differing sets of guidance).

To workaround these upstream inconsistencies, we're moving towards having the Provider define the Resource ID for a given Resource (typically using the Azure Resource ID for a given Resource, but following the camelCase values that the ARM Team are requiring for Resource Types going forwards) - as outlined in the comment that @WodansSon has linked above - but this is being done as resources are migrated over to hashicorp/go-azure-sdk.

Thanks, this workaround works for now

Glad to hear this is now working for you, since this has been resolved I'm going to close this issue for the moment 👍

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.