data source azurerm_network_service_tag produces incorrect results in AzureRM >= 3.69.0

[vsabella]

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.5.7

AzureRM Provider Version

3.69.0

Affected Resource(s)/Data Source(s)

data azurerm_network_service_tags

Terraform Configuration Files

# regional service
data "azurerm_network_service_tags" "storage" {
  location        = "westus2"
  service         = "Storage"
  location_filter = "westus2"
}

Debug Output/Panic Output

see above

Expected Behaviour

In 3.68.0 or earlier, the ID field is equal to the actual Service Tag from the api response. This is good because they are case sensitive if used in things like Firewall rules.
{
+ address_prefixes = [] # bunch of ips...
+ id = "Storage.WestUS2"
+ ipv4_cidrs = [] # bunch of ips...
+ ipv6_cidrs = [] # bunch of ips...
+ location = "westus2"
+ location_filter = "westus2"
+ service = "Storage"
+ timeouts = null

Actual Behaviour

In 3.69.0 or later, the ID field was changed (see 05a8abd#diff-ab68d1e4cc83749bc5f8f38b2fca60a4cb541c904f1275cf32eaf82dc8805d82R129)

This is bad because you cannot use "Storage.westus2" as a network storage tag safely, it will result in infinite drift between runs as the backend service corrects it to "Storage.WestUS2"

We expect the actual Azure API response to be returned, not a modified version of it, or at least the "Name" field returned from the Azure ID

• b = {
  • address_prefixes = []
    + id = "westus2-Storage"
  • ipv4_cidrs = []
  • ipv6_cidrs = []
  • location = "westus2"
  • location_filter = "westus2"
  • service = "Storage"
  • timeouts = null
    }

Steps to Reproduce

basica terraform plan/apply

Important Factoids

No response

References

05a8abd

[vsabella]

@tombuildsstuff this is an example from the Azure API response

{
      "id": "Storage.WestUS2",
      "name": "Storage.WestUS2",
      "properties": {
        "addressPrefixes": [
          "13.66.176.16/28",
          "13.66.176.48/28",
          "13.66.232.64/28",
          "13.66.232.208/28",
          "13.66.232.224/28",
          "13.66.234.0/27",
          "13.77.184.64/28",
          "20.33.160.0/24",
          "20.38.99.0/24",
          "20.47.62.0/23",
          "20.60.20.0/24",
          "20.60.68.0/22",
          "20.60.152.0/23",
          "20.60.228.0/23",
          "20.150.68.0/24",
          "20.150.78.0/24",
          "20.150.87.0/24",
          "20.150.107.0/24",
          "20.157.50.0/23",
          "20.157.180.0/24",
          "20.157.249.0/24",
          "20.209.100.0/23",
          "20.209.154.0/23",
          "20.209.186.0/23",
          "52.183.48.16/28",
          "52.183.104.16/28",
          "52.183.104.32/28",
          "52.191.176.16/28",
          "52.191.176.32/28",
          "52.239.148.128/25",
          "52.239.176.128/25",
          "52.239.193.0/24",
          "52.239.210.0/23",
          "52.239.236.0/23",
          "2603:1030:d01::/48"
        ],
        "changeNumber": "9",
        "region": "westus2",
        "state": "GA",
        "systemService": "AzureStorage"
      },
      "serviceTagChangeNumber": "152"
    },

[wuxu92]

Hi @vsabella Thanks for raising this issue! The data source ID has been intentionally changed in the current provider version, as mentioned in the commit link provided. Would exposing the name of the service tag to the data source help to address this issue? @tombuildsstuff WDYT?

[vsabella]

@wuxu92 yes, exposing the name of the service tag would work :)

[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.