Unwanted Reprovision of terraform resources

rishab-sgid 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

Terraform Version

Terraform v1.5.2

AzureRM Provider Version

3.40.0

Affected Resource(s)/Data Source(s)

azurerm_management_lock

Terraform Configuration Files

resource "azurerm_management_lock" "management_azurerm_kusto_cluster" {
  for_each = local.kusto_cluster

  name       = kustocluster
  scope      = azurerm_kusto_cluster.kusto_cluster[kustocluster].id
  lock_level = "CanNotDelete"
}

resource "azurerm_management_lock" "management_azurerm_kusto_database" {
  for_each = local.kusto_database

  name       = each.value.name
  scope      = azurerm_kusto_database.kusto_database[each.value.name].id
  lock_level = "CanNotDelete"
}

and may more similar resources

Debug Output/Panic Output

-/+ resource "azurerm_management_lock" "management_azurerm_kusto_cluster" {
~ id = "/subscriptions/xxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxx/resourceGroups/fsight-stg-rg-adx/providers/Microsoft.Kusto/Clusters/fsightstgkustocluster/providers/Microsoft.Authorization/locks/kustocluster" -> (known after apply)
name = "kustocluster"
~ scope = "/subscriptions/xxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxx/resourceGroups/fsight-stg-rg-adx/providers/Microsoft.Kusto/Clusters/fsightstgkustocluster" -> "/subscriptions/xxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxx/resourceGroups/fsight-stg-rg-adx/providers/Microsoft.Kusto/clusters/fsightstgkustocluster" # forces replacement
# (1 unchanged attribute hidden)
}

 # azurerm_management_lock.management_azurerm_kusto_database["kusto-database"] must be replaced
 -/+ resource "azurerm_management_lock" "management_azurerm_kusto_database" {
 ~ id         = "/subscriptions/xxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxx/resourceGroups/fsight-stg-rg-adx/providers/Microsoft.Kusto/Clusters/fsightstgkustocluster/Databases/fsight-stg-kusto-database/providers/Microsoft.Authorization/locks/kusto-database" -> (known after apply)
  name       = "kusto-database"
  ~ scope      = "/subscriptions/xxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxx/resourceGroups/fsight-stg-rg-adx/providers/Microsoft.Kusto/Clusters/fsightstgkustocluster/Databases/fsight-stg-kusto-database" -> "/subscriptions/xxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxx/resourceGroups/fsight-stg-rg-adx/providers/Microsoft.Kusto/clusters/fsightstgkustocluster/databases/fsight-stg-kusto-database" # forces replacement
  # (1 unchanged attribute hidden)
  }

  # azurerm_management_lock.management_lock_iothub["iothub"] must be replaced
  -/+ resource "azurerm_management_lock" "management_lock_iothub" {
  ~ id         = "/subscriptions/xxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxx/resourceGroups/fsight-stg-rg-iot/providers/Microsoft.Devices/IotHubs/fsight-stg-iothub/providers/Microsoft.Authorization/locks/iothub" -> (known after apply)
   name       = "iothub"
   ~ scope      = "/subscriptions/xxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxx/resourceGroups/fsight-stg-rg-iot/providers/Microsoft.Devices/IotHubs/fsight-stg-iothub" -> "/subscriptions/xxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxx/resourceGroups/fsight-stg-rg-iot/providers/Microsoft.Devices/iotHubs/fsight-stg-iothub" # forces replacement
   # (1 unchanged attribute hidden)
   }

Expected Behaviour

Terraform resources mentioned in output should not have been replaced, they should not appear in output of terraform plan commands as no value is changed explicitly.

Actual Behaviour

Due to change in letters of scope, this is causing forceful replacement of resources. As seen below apart from highlighted words nothing have changed, this is causing our resources to destroy and reprovision

scope = "/subscriptions/xxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxx/resourceGroups/fsight-stg-rg-adx/providers/Microsoft.Kusto/Clusters/fsightstgkustocluster/Databases/fsight-stg-kusto-database" -> "/subscriptions/xxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxx/resourceGroups/fsight-stg-rg-adx/providers/Microsoft.Kusto/clusters/fsightstgkustocluster/databases/fsight-stg-kusto-database" # forces replacement

Steps to Reproduce

terraform init terraform plan

Important Factoids

Azurerm version used is terraform { required_providers { azurerm = { source = "hashicorp/azurerm" version = "3.40.0" } } backend "azurerm" { } } provider "azurerm" { features {} skip_provider_registration = true } we are using Terraform OSS and state file is maintained remotely.

References

No response

rishab-sgid commented 1 year ago

@rcskosir, can someone help me with this issue ?

schnabel45 commented 1 year ago

Adding that I'm seeing the same in 3.41.0. It appears that the capital C for "Clusters" was changed to a lower case c which is what is forcing an unintended replacement. Attempting to bold the issue below, but it's still hard to see.

"/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-name/providers/Microsoft.Kusto/Clusters/adxcluster" "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-name/providers/Microsoft.Kusto/clusters/adxcluster"

rishab-sgid commented 1 year ago

@schnabel45

Yes, I can clearly see the issue. But is there any workaround through which we can tackle this situation. If you find any solution, do let me know. I am still figuring out how can this be avoided.

schnabel45 commented 1 year ago

@rishab-sgid Sorry I wasn't trying to say you didn't see the issue. It just took me a few minutes to realize what was going on so I wanted to point it out for everyone.

At this time, the only thing I can say is that the regression started in 3.35.0, I sequentially upgraded my provider from the version we had been running (3.32.0) until an apply started forcing a replacement. I'm not sure of a work around yet (outside of pinning the version to 3.34.0 for now).

schnabel45 commented 1 year ago

I believe this is related to #19525. v3.35.0 introduced a kusto migration plan related to resource ID casing issues. I'm just now diving into the diff to see if anything stands out.

dcfsc commented 1 year ago

We run into this with resourceGroup vs resourcegroup in ARM ids. You could try.

locals {
  your_resource_id = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-name/providers/Microsoft.Kusto/clusters/adxcluster"

}
...

scope = replace(locals.your_resource_id , "clusters", "Clusters")

Which ever way you need the caps to work. Sometimes this lets the plan run cleanly. It is a hack until Terraform and Azure get their case consistent.

hashicorp / terraform-provider-azurerm