azurerm_subnet data source returns subnet id capitalised based on input params, not retrieved id.

tony-harverson-moonpig commented 1 year ago

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 "+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.6.3

AzureRM Provider Version

3.80.0

Affected Resource(s)/Data Source(s)

data "azurerm_subnet"

Terraform Configuration Files

terraform {
  required_version = "~> 1.6.3"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "3.80"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_subnet" "test" {
  name                 = "LOWERCASE"
  resource_group_name  = "sPIKE"
  virtual_network_name = "testNETWORK"
}

output "subnet_id" {
  value = data.azurerm_subnet.test.id
}

Debug Output/Panic Output

> terraform plan
data.azurerm_subnet.test: Reading...
data.azurerm_subnet.test: Read complete after 1s [id=/subscriptions/{subscription_id}/resourceGroups/sPIKE/providers/Microsoft.Network/virtualNetworks/testNETWORK/subnets/LOWERCASE]

Changes to Outputs:
  + subnet_id = "/subscriptions/{subscription_id}/resourceGroups/sPIKE/providers/Microsoft.Network/virtualNetworks/testNETWORK/subnets/LOWERCASE"

> az rest --method GET --uri https://management.azure.com/subscriptions/{subscription_id}/resourceGroups/sPIKE/providers/Microsoft.Network/virtualNetworks/TestNETWORK/subnets/LOWERCASE?api-version=2023-05-01
{
  "etag": "W/\"a6e9307e-6fa4-4cf1-bb30-0909a54bb165\"",
  "id": "/subscriptions/{subscription_id}/resourceGroups/Spike/providers/Microsoft.Network/virtualNetworks/TestNetwork/subnets/lowercase",
  "name": "lowercase",
  "properties": {
    "addressPrefix": "10.0.2.0/24",
    "delegations": [],
    "privateEndpointNetworkPolicies": "Disabled",
    "privateLinkServiceNetworkPolicies": "Enabled",
    "provisioningState": "Succeeded",
    "serviceEndpoints": []
  },
  "type": "Microsoft.Network/virtualNetworks/subnets"
}

Expected Behaviour

Changes to Outputs:
  + subnet_id = "/subscriptions/{subscription_id}/resourceGroups/spike/providers/Microsoft.Network/virtualNetworks/TestNetwork/subnets/lower"

Note the capitalisation of the Resource group name and the subnet name id is as returned from the rest api, not based on the capitalisation of the inputs.

Actual Behaviour

The subnet id returned from the data lookup is capitalised based on the input parameters, not the id as returned by the azure api. This has caused us issues when the id is used as an input to resources like application gateway's network configurataion, resulting in a never-settling terraform plan, because the subnet id returned from the azure api is returned with the actual capitalisation of the object id..

Steps to Reproduce

Create a resource group called spike containing a virtual network callled "TestNetwork" containing a subnet called "lowercase".

Terraform plan

Important Factoids

No response

References

No response

wuxu92 commented 1 year ago

Hi @tony-harverson-moonpig , Thank you for reporting this. Actually, the provider designed it so that the ID of the data source prioritizes user input over API response. Is there specific reasion for using a different cased name instead of the correct one?

tony-harverson-moonpig commented 1 year ago

Hi @wuxu92. No, we don't have a specific reason for using different capitalisation. We discovered this when an input was mistakenly capitalised differently to the actual subnet id, and we've fixed our issue by correcting the casing of the inputs.

The current behaviour seems confusing for a data source - I think most engineers would expect the data source to return the id as it exists in the api when looking it up. Especially as using the mis-cased id as an input to other resources may cause issues.

wuxu92 commented 1 year ago

@tony-harverson-moonpig thank you for clarifying! As far as I know, the resource ID from Azure API can vary between services and sometimes the API does not return the ID capitalized correctly/expectedly. I believe this is why the provider prefers to use user input to construct the data source ID (There are still some of data sources use the ID returned from API but most of them are not).

hashicorp / terraform-provider-azurerm