azurerm_storage_container: migrating from storage_account_name to storage_account_id forces replacement

[SanderBlom]

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

AzureRM Provider Version

4.9.0

Affected Resource(s)/Data Source(s)

azurerm_storage_container

Terraform Configuration Files

resource "azurerm_storage_account" "app_assets" {
  name                     = "random_name"
  resource_group_name      = data.azurerm_resource_group.workload.name
  location                 = data.azurerm_resource_group.workload.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
  account_kind             = "StorageV2"
  tags                     = var.tags
}

resource "azurerm_storage_container" "app_files" {
  name                  = "files"
  storage_account_id    = azurerm_storage_account.app_assets.id
  container_access_type = "private"
}

Debug Output/Panic Output

# azurerm_storage_container.app_files must be replaced
-/+ resource "azurerm_storage_container" "app_files" {
      ~ default_encryption_scope          = "$account-encryption-key" -> (known after apply)
      ~ has_immutability_policy           = false -> (known after apply)
      ~ has_legal_hold                    = false -> (known after apply)
      ~ id                                = "https://random_name.blob.core.windows.net/files" -> (known after apply)
      ~ metadata                          = {} -> (known after apply)
        name                              = "files"
      ~ resource_manager_id               = "/subscriptions/x/resourceGroups/y/providers/Microsoft.Storage/storageAccounts/z/blobServices/default/containers/files" -> (known after apply)
      + storage_account_id                = "/subscriptions/x/resourceGroups/y/providers/Microsoft.Storage/storageAccounts/z" # forces replacement
      - storage_account_name              = "random_name" -> null # forces replacement
        # (2 unchanged attributes hidden)
    }

Expected Behaviour

I expect that when we get promted by a warning that: thestorage_account_nameproperty has been deprecated in favour ofstorage_account_idand will be removed in version 5.0 of the Provider. I then would expect that when we change from using the storage_account_name to the storage_account_id that it will not try to recreate the storage account but just plan with 0 changes.

Actual Behaviour

When running a plan I get the message that the azurerm_storage_account has to be recreated because we have added the storage_account_id property and that we have removed the storage_account_name

Steps to Reproduce

Create a new storage account and a new storage container where you use the storage_account_name property to reference the storage account. After the resources have been created, try to change from using the storage_account_name to the storage_account_id and observe the plan output.

Important Factoids

No response

References

No response

[Fatalo83]

The same issue occurs with the azurerm_storage_share resource. The following example also forces a replacement.

resource "azurerm_storage_share" "file_share" {
  name               = "example"
  #storage_account_name = azurerm_storage_account.example.name
  storage_account_id = azurerm_storage_account.example.id
  quota              = 100
}

[radurobot]

Here's a quick fix until this is resolved:

1. Option 1: Add a lifecycle block with ignore_changes for storage_account_name.

2. Option 2: Update the azurerm_storage_container resource by removing storage_account_name and adding storage_account_id:

   resource "azurerm_storage_container" "containerName" {
    name                  = "mycontainer"
    storage_account_id    = azurerm_storage_account.example.id
    container_access_type = "private"
   }

   Then, run the following commands:

   terraform state rm azurerm_storage_container.containerName
   terraform import azurerm_storage_container.containerName <resource_manager_id>

If you check the state file after doing this, you might notice azurerm_storage_container is gone, I'm not sure if this should happen or not.

[eric-mark]

We have also ran into the same issue (from the original post) and noticed that the container was destroyed in our lower environment.

[enorlando]

We are also seeing the azurerm_role_assignment resources wanting to be re-created when using azurerm_storage_share.xx.resource_manager_id as the scope.

[gerhard-strauss-jambit]

you can re-import those Ressource, so that you dont have to re-create them.

terraform state rm azurerm_storage_container.containerName
terraform import azurerm_storage_container.containerName <resource_manager_id>

The Important Part is to use the resource_manager_id, not the url. e.g. terraform import azurerm_storage_container.containerName /subscriptions/12345678-1234-9876-4563-123456789012/resourceGroups/example-resource-group/providers/Microsoft.Storage/storageAccounts/storageAccountName/blobServices/default/containers/ContainerName

if you do a Plan before, you can see the current resource_manager_id and use it in case of Blob. in my Tests, the resource_manager_id shown on File Shares was incorrect. on Position 10 it was printed with "fileshares" instead of "shares"

[peruzzof]

I have too many repos to adjust state in all environments and the other workaround was not enough as adding the account_id is enough to trigger a replacement. I will postpone this version, is there any plan to implement a proper fix in the code?

[shacal]

@peruzzof - Same here... this "migration" will be pain in the ass.

│ This property has been deprecated and will be replaced by storage_account_id in version 5.0 of the provider. │ │ (and 3463 more similar warnings elsewhere)

[tw-sematell]

Seriously, this should just work.