-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replacing a Storage Account Does Not Replace Dependent Resources #13106
Comments
@tombuildsstuff Would you accept a similar PR as #13307 (i.e. deprecating the old way with RG/name, and add an option to provide the account id instead) for |
@alxy - this comment reminded me that I was sitting on a half-baked contribution to move this forward. I saw that my original PR was adapted to better leverage the feature flags, and specifically the flags that were leveraged as part of the 3.0 upgrade. I took a similar approach and used 4.0 flags to wrap up backwards-compatible functionality and deprecation warnings. The downside is that I found another 3 resources that are bitten by this same bug. 🙁 |
Confirming this problem affects azurerm_storage_share. To reproduce:
|
A little more on the above azurerm_storage_share issue. As in the above comment, this is only dependent on the storage_account_name so any action that re-creates the storage account without changing its name looks like no change to this resource. The comment above isn't accurate though: the resource remains in the tf state but the share in Azure is destroyed along with the storage account. A second plan and apply notices the fileshare is in the state but not in Azure; it thinks you deleted it manually and then re-creates it. If anyone else gets here with the same issue, you can work around, not with
|
This also affects Unfortunately, using |
Community Note
Terraform (and AzureRM Provider) Version
Affected Resource(s)
azurerm_storage_account_network_rules
azurerm_container_group
azurerm_databricks_workspace
azurerm_function_app
azurerm_media_asset
azurerm_service_fabric_cluster
azurerm_storage_blob
azurerm_storage_container
azurerm_storage_queue
azurerm_storage_share
azurerm_storage_share_directory
azurerm_storage_table
azurerm_storage_table_entity
azurerm_stream_analytics_output_blob
azurerm_stream_analytics_reference_input_blob
azurerm_stream_analytics_stream_input_blob
All of the above resources have a schema that references the name of a storage account (and not the ID). I suspect that some/all of these will not be replaced in the event a storage account is replaced.
Terraform Configuration Files
Expected Behaviour
Terraform recreates storage account network rules when the underlying storage account is replaced.
Actual Behaviour
Replaced storage accounts have default network rules in place
Steps to Reproduce
terraform apply
terraform taint azurerm_storage_account.sa
terraform apply
The text was updated successfully, but these errors were encountered: