azurerm_storage_container is not recreated when azurerm_storage_account must be replaced

[alaczynski]

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

Terraform (and AzureRM Provider) Version

Affected Resource(s)

• azurerm_storage_container
• azurerm_storage_account

Terraform Configuration Files

resource "azurerm_resource_group" "this" {
  name     = "some-rg"
  location = var.location
  tags     = var.tags
}

resource "azurerm_storage_account" "this" {
  account_replication_type = "LRS"
  account_tier             = "Standard"
  location                 = azurerm_resource_group.this.location
  name                     = "somestorage1"
  resource_group_name      = azurerm_resource_group.this.name
  is_hns_enabled           = false
  tags                     = azurerm_resource_group.this.tags
}

resource "azurerm_storage_container" "container1" {
  name                  = "container1"
  storage_account_name  = azurerm_storage_account.this.name
  container_access_type = "private"
}

Debug Output

Panic Output

Expected Behaviour

azurerm_storage_container should be recreated when storage account is being replaced

Actual Behaviour

after terraform apply container does not exist because account was recreated, container was not included in the plan (container cannot exist without account so this was wrong assumption)

Steps to Reproduce

1. terraform apply
2. change azurerm_storage_account config to trigger replacement, e.g. is_hns_enabled -> true
3. terraform apply
   • contain is not included in applied changes

Important Factoids

References

• #0000

[magodo]

@alaczynski Thank you for submitting this!

The reason why the container is not marked as to be replaced is the name of the storage account is not marked as ForceNew when the resource is to be replaced. Idealy, the container should refer to the id of the storage account, which will be reflected in case the account is to be replaced, which will result into the container being replaced. Since this is a breaking change on the storage container, we will have to defer to resolving this issue in v3.0.0.

[owenfarrell]

@sharebear - I ran in to a similar issue with network ACL rules. And after doing a bit of digging, I found 14 resources that I think have the exact same issue (of which azurerm_storage_container is 1 of the 14). I've summarized my findings on #13106.

I totally agree with @magodo - the fact that these dependent resources reference the storage account name (and resource group) instead of the ID means that resources dependent on storage accounts aren't being recreated when the storage account itself is being recreated.

[stephybun]

I believe this is resolved, storage_account_name in azurerm_storage_container is marked as ForceNew so I'm going to close this issue. If this behaviour still persists on the latest version of the provider let us know and we can reopen this. Thanks!

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