terraform-provider-azurerm: Intermittent Error: Unable to locate Storage Account "<>"!
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
1.35.0 1.36.0 1.37.0 1.38.0 1.39.0
Description
I am getting this error intermittently when using azurerm provider 1.35.0, 1.36.0, 1.37.0, 1.38.0, 1.39.0. This issue doesnot occur on azurerm provider 1.34.0 and on earlier versions.
Anyone else had seen this issue. Below is the log for terraform plan command
2020-01-03T14:29:08.9014786Z ##[section]Starting: Terraform plan
2020-01-03T14:29:08.9018892Z ==============================================================================
2020-01-03T14:29:08.9018984Z Task : Terraform
2020-01-03T14:29:08.9019106Z Description : Execute terraform commands to manage resources on AzureRM, Amazon Web Services(AWS) and Google Cloud Platform(GCP)
2020-01-03T14:29:08.9019365Z Version : 0.0.142
2020-01-03T14:29:08.9019475Z Author : Microsoft Corporation
2020-01-03T14:29:08.9019548Z Help : [Learn more about this task](https://aka.ms/AA5j5pf)
2020-01-03T14:29:08.9019668Z ==============================================================================
2020-01-03T14:29:09.0425642Z [command]/opt/hostedtoolcache/terraform/0.12.17/x64/terraform providers
2020-01-03T14:29:09.5124944Z .
2020-01-03T14:29:09.5126416Z āāā provider.azurerm =1.39.0
2020-01-03T14:29:09.5126663Z
2020-01-03T14:29:09.5157691Z [command]/opt/hostedtoolcache/terraform/0.12.17/x64/terraform plan -var-file=envs/dev/vars.auto.tfvars -out=tfplan -no-color -input=false
2020-01-03T14:29:11.1176401Z Refreshing Terraform state in-memory prior to plan...
2020-01-03T14:29:11.1179110Z The refreshed state will be used to calculate this plan, but will not be
2020-01-03T14:29:11.1179729Z persisted to local or remote state storage.
2020-01-03T14:29:11.1180065Z
2020-01-03T14:29:13.9250714Z data.azurerm_resource_group.power: Refreshing state...
2020-01-03T14:29:13.9614330Z azurerm_key_vault.xxxxxxxxxx: Refreshing state... [id=/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxx/resourceGroups/rg-name/providers/Microsoft.KeyVault/vaults/mykv]
2020-01-03T14:29:13.9639469Z azurerm_storage_account.power_storage_account: Refreshing state... [id=/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxx/resourceGroups/rg-name/providers/Microsoft.Storage/storageAccounts/mysa]
2020-01-03T14:29:13.9644189Z azurerm_application_insights.power_app_insights: Refreshing state... [id=/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxx/resourceGroups/rg-name/providers/microsoft.insights/components/myai-we]
2020-01-03T14:29:13.9656039Z azurerm_app_service_plan.func_apps_consumption_plan: Refreshing state... [id=/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxx/resourceGroups/rg-name/providers/Microsoft.Web/serverfarms/mycsp]
2020-01-03T14:29:14.1513932Z azurerm_key_vault_access_policy.spn_access_policy: Refreshing state... [id=/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxx/resourceGroups/rg-name/providers/Microsoft.KeyVault/vaults/myvault/objectId/xxxxx-xxxx-xxxx-xxxxx]
2020-01-03T14:29:16.1417214Z
2020-01-03T14:29:16.1418746Z Error: Unable to locate Storage Account "mysa"!
2020-01-03T14:29:16.1418814Z
2020-01-03T14:29:16.1418851Z
2020-01-03T14:29:16.2364297Z ##[error]Error: The process '/opt/hostedtoolcache/terraform/0.12.17/x64/terraform' failed with exit code 1
2020-01-03T14:29:16.2381103Z ##[section]Finishing: Terraform plan
Terraform Configuration Files
# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key: https://keybase.io/hashicorp
data "azurerm_resource_group" "power" {
name = var.resource_group_name
}
resource "azurerm_storage_account" "power_storage_account" {
name = "${var.product_code}sa${var.env_code}${var.location_code_we}"
resource_group_name = data.azurerm_resource_group.power.name
location = var.location
account_tier = var.storage_account_tier
account_replication_type = var.storage_account_replication_type
account_kind = "StorageV2"
enable_https_traffic_only = true
tags = var.default_tags
}
resource "azurerm_application_insights" "power_app_insights" {
name = "${var.product_code}-df-${var.env_code}-ai-${var.location_code_we}"
location = var.location
resource_group_name = data.azurerm_resource_group.power.name
application_type = "web"
tags = var.default_tags
}
Debug Output
Panic Output
Expected Behavior
It should locate the existing storage account
Actual Behavior
Error: Unable to locate Storage Account ā<<storage_account_name>>ā!
Steps to Reproduce
terraform apply
Important Factoids
References
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 45
- Comments: 27 (9 by maintainers)
Commits related to this issue
- r/storage_account: populating the cache on creation Fixes #5299 — committed to hashicorp/terraform-provider-azurerm by tombuildsstuff 3 years ago
Recently we see a lot of issues introduced by this error,
Iām assuming itās a issue caused by Azure Storage account List API handling in terraform-azurerm-provider because of following reasons, will try to collect debug logs in places that reproducing this error to prove the assumption.
Behaviors:
Short term workarround:
Potential long term solution:
Iāve started seeing this error using azurerm
v2.52.0
Any updates on this??
same problem here⦠We are using the version 2.9 and got the same problem We have to run the script twice to mount the storage.
We got some updates after troubleshooting with MSFT, the List API will response 200 OK with empty list that causes this issue, when Azure Management Storage Provider Limits hit: https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#storage-resource-provider-limits it usually should response with 429, but the List accounts API is misbehaving on this scenario
We get this issue either on a āterraform applyā or a āterraform planā and itās completely intermittent, happening for us 20-30% of the time (without having changed anything). It seems terraform is unable to find the storage account intermittently.
Oddly enough, for us this can even happen when the storage account in question even exists as a resource within the main.tf terraform config e.g.: ` data.azurerm_resource_group.main: Refreshing state⦠module.storage_account.data.azurerm_client_config.current: Refreshing state⦠module.storage_account.data.azurerm_resource_group.main: Refreshing state⦠module.storage_account.azurerm_storage_account.storage_account: Refreshing state⦠[id=/subscriptions/xxxx/resourceGroups/xxxx/providers/Microsoft.Storage/storageAccounts/mystorageaccount] module.azure_function.data.azurerm_resource_group.main: Refreshing state⦠module.azure_function.data.azurerm_client_config.current: Refreshing state⦠module.azure_function.azurerm_application_insights.insights: Refreshing state⦠[id=/subscriptions/xxxx/resourceGroups/xxxx/providers/microsoft.insights/components/xxxx] module.azure_function.azurerm_app_service_plan.plan: Refreshing state⦠[id=/subscriptions/xxxx/resourceGroups/xxxx/providers/Microsoft.Web/serverfarms/xxxx] azurerm_storage_container.images_container: Refreshing state⦠[id=https://mystorageaccount.blob.core.windows.net/images] module.azure_function.module.storage_account_for_function.data.azurerm_resource_group.main: Refreshing state⦠module.azure_function.module.storage_account_for_function.data.azurerm_client_config.current: Refreshing state⦠module.azure_function.module.storage_account_for_function.azurerm_storage_account.storage_account: Refreshing state⦠[id=/subscriptions/xxxx/resourceGroups/xxxx/providers/Microsoft.Storage/storageAccounts/mystorageaccount]
Error: Unable to locate Storage Account āmystorageaccountā! `
This is frustrating though as it leads to our pipelines to fail intermittently through no fault of our own