azurerm_api_management reports the subnet is changing with the identical id every run

jfe7 commented 2 years 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

Terraform Version

1.1.7

AzureRM Provider Version

2.99.0

Affected Resource(s)/Data Source(s)

azurerm_api_management

Terraform Configuration Files

resource "azurerm_api_management" "apim_01" {
  name                 = "apim-${var.project}-${var.env}-${var.workload}-${var.location}-01"
  location             = azurerm_resource_group.rg_01.location
  resource_group_name  = azurerm_resource_group.rg_01.name
  publisher_name       = "James"
  publisher_email      = "james@james.com"
  sku_name             = var.apim_sku
  virtual_network_type = "Internal"

  virtual_network_configuration {
    subnet_id = azurerm_subnet.snet_apim_01.id
  }

  identity {
    type = "SystemAssigned"
  }
}

Debug Output/Panic Output

no debug output.

Expected Behaviour

Terraform reports no changes to the API Management subnet.

Actual Behaviour

Every time I run Terraform Plan, Terraform reports that the subnet on the API Management resource is changing, even though it reports the change as being an identical subnet ID, for example below:

# azurerm_api_management.apim_01 will be updated in-place
  ~ resource "azurerm_api_management" "apim_01" {
        id                            = "/subscriptions/00000000-000000000000000-000000000/resourceGroups/rg-01/providers/Microsoft.ApiManagement/service/apim-01"
        name                          = "apim-01"
        tags                          = {}
        # (20 unchanged attributes hidden)

      ~ virtual_network_configuration {
          ~ subnet_id = "/subscriptions/00000000-000000000000000-000000000/resourceGroups/rg-01/providers/Microsoft.Network/virtualNetworks/vnet-01/subnets/snet-01" -> "/subscriptions/00000000-000000000000000-000000000/resourceGroups/rg-01/providers/Microsoft.Network/virtualNetworks/vnet-01/subnets/snet-01"
        }
        # (6 unchanged blocks hidden)
    }

Steps to Reproduce

terraform plan

Important Factoids

No response

References

No response

tombuildsstuff commented 2 years ago

@jfe7 taking a look through above unfortunately the Resource IDs have been sanitised/show no differences, so it's hard to confirm the specific issue here - would you be able to confirm the Resource IDs in question?

jfe7 commented 2 years ago

I can't post the exact output due to security reasons... I have just replaced the subscription id with 0's.

but that is exactly the point I am making, the change Terraform is stating, is not actually a change, it is replacing the subnet_id with exactly the same subnet_id as it was before:

~ virtual_network_configuration {
          ~ subnet_id = "/subscriptions/00000000-000000000000000-000000000/resourceGroups/rg-01/providers/Microsoft.Network/virtualNetworks/vnet-01/subnets/snet-01" -> "/subscriptions/00000000-000000000000000-000000000/resourceGroups/rg-01/providers/Microsoft.Network/virtualNetworks/vnet-01/subnets/snet-01"
        }

tombuildsstuff commented 2 years ago

@jfe7 without the difference in the Resource ID being shown unfortunately we're unable to assist much further here, is there a difference in casing perhaps?

jfe7 commented 2 years ago

@jfe7 without the difference in the Resource ID being shown unfortunately we're unable to assist much further here, is there a difference in casing perhaps?

Yes that looks like the issue, the case, the current subnet ID, everything is in lowercase, where-as the one it wants to change it to, has some capital letters, for example /virtualnetwork/ vs /virtualNetwork/, not sure why it is changing this every run?

Anyway, looks like the issue is resolved in 3.X.X as I upgraded the provider and this issue never occurred, must just be an issue in the later versions of 2.X.X !

Thanks

tombuildsstuff commented 2 years ago

@jfe7 glad to hear this is resolved in 3.0 - closing this out.

github-actions[bot] commented 2 years ago

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.

hashicorp / terraform-provider-azurerm