azurerm_platform_image datasource returns unexpected case reference_ID

[davejdeemer]

Is there an existing issue for this?

• [X] I have searched the existing issues

Community Note

• Please vote on this issue by adding a :thumbsup: 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.8.5

AzureRM Provider Version

3.107.0

Affected Resource(s)/Data Source(s)

azurerm_platform_image

Terraform Configuration Files

terraform {
  required_providers {
    azurerm = {
      version = "= 3.107.0"
    }
  }
}

provider "azurerm" {
  subscription_id = ""
  features {}
}

data "azurerm_platform_image" "palo_fw_image" {
  location  = "North Central US"
  publisher = "paloaltonetworks"
  offer     = "vmseries-flex"
  sku       = "byol"
  version   = "10.0.7"
}

output "id" {
  value = data.azurerm_platform_image.palo_fw_image.id
}

Debug Output/Panic Output

data.azurerm_platform_image.palo_fw_image: Reading...
data.azurerm_platform_image.palo_fw_image: Read complete after 1s [id=/subscriptions/<subscription_id>/providers/Microsoft.Compute/locations/northcentralus/publishers/paloaltonetworks/artifactTypes/vmImage/offers/vmseriesflex/skus/byol/versions/10.0.7]

Changes to Outputs:
  + id = "/subscriptions/<subscription_id>/providers/Microsoft.Compute/locations/northcentralus/publishers/paloaltonetworks/artifactTypes/vmImage/offers/vmseries-flex/skus/byol/versions/10.0.7"

Expected Behaviour

The datasource ought to return the same case as does the azCLI and the reference ID from a VM created from the image.

Actual Behaviour

The datasource returns a different case resource ID than expected which causes the AzureRM provider to detect a change from prior-created VMs from this image when no change has actually been made to the VM configuration.

Output from the datasource: /subscriptions/<subscription>/providers/Microsoft.Compute/locations/northcentralus/publishers/paloaltonetworks/artifactTypes/vmImage/offers/vmseries-flex/skus/byol/versions/10.0.7

Output from the azCLI (and from a reference ID from a prior created VM from this image): /Subscriptions/<subscription>/Providers/Microsoft.Compute/Locations/northcentralus/Publishers/paloaltonetworks/ArtifactTypes/VMImage/Offers/vmseries-flex/Skus/byol/Versions/10.0.7

Steps to Reproduce

1. terraform plan
2. Observe the image ID returned (note the capitalization)
3. Query the image via the AzureCLI az vm image show --location northcentralus --urn paloaltonetworks:vmseries-flex:byol:10.0.7
4. Observe the image ID returned (note the capitalization)

Important Factoids

n/a

References

No response

[wuxu92]

Hi @davejdeemer Thanks for raising this issue. The issue appears to be more related to azCli than the AzureRM provider. The static segments, like locations and publishers, should be lowercase as defined in the Swagger file.: https://github.com/Azure/azure-rest-api-specs/blob/7aacb10759f40121fc79c52080e0b0e840d6a329/specification/compute/resource-manager/Microsoft.Compute/ComputeRP/stable/2024-03-01/virtualMachineImage.json#L37

"paths": {
    "/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/publishers/{publisherName}/artifacttypes/vmimage/offers/{offer}/skus/{skus}/versions/{version}": {
      "get": {

[davejdeemer]

Oh! Interesting... I wonder if someone in my org had created the VM via the azCLI, then imported that state and is now why it's a problem on subsequent plan/applies.

Although; the datasource response still doesn't follow what's noted in the swagger file; take a look at artifactTypes:

• From the datasrouce: artifactTypes
• From Swagger: artifacttypes

[tombuildsstuff]

@davejdeemer FWIW the Key segments within the Resource ID are supposed (per the ARM specification) to be camelCase rather than TitleCase, lowercase etc - unfortunately different Azure APIs implement a different set of behaviours (although they're supposed to be case-insensitive in requests, and case-sensitive in responses, but many differ in subtly different ways).

From our side hashicorp/go-azure-sdk provides Resource ID types which normalize the casing of the Resource ID segments to ensure these are camelCased - meaning that when validating Resource IDs from our side (or creating new resources) that camelCasing is used. Whilst on the whole we're trying to normalize the values coming back from the Azure API such that we'll re-case these values for consistency (which'll avoid spurious diffs going forwards) - as the Azure CLI is just returning the raw value from the Azure API here, that recasing isn't being applied and hence this difference in values.

As such this is less of a Terraform/Azure CLI issue and more that the Azure API uses casing in a widely inconsistent manner - so I'm hoping that helps explain this?

Thanks!

[davejdeemer]

That makes sense and I appreciate you taking the time to respond. I know I've seen the same thing pop up for other resources and can imagine that if the API isn't consistent with returning values that makes things pretty challenging.

I'll close this issue in light of what you've shared as it seems there are many factors in the mix for this.

[github-actions[bot]]

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.