Open RoyC7 opened 2 years ago
I got this on a deployment this morning too, first time ever on TF code that hasn't changed for a long while. Very similar error to yours.
Error: Provider produced inconsistent final plan
When expanding the plan for
module.aks.azurerm_key_vault_secret.aks_admin_client_certificate to include
new values learned so far during apply, provider
"registry.terraform.io/hashicorp/azurerm" produced an invalid new value for
.value: inconsistent values for sensitive attribute.
This is a bug in the provider, which should be reported in the provider's own
issue tracker.
Same for me, but I noticed that the secret will be created on the Key Vault.
resource "azurerm_key_vault_secret" "this" {
name = var.secret_name
key_vault_id = azurerm_key_vault.this.id
value = var.secret
}
Terraform v1.1.6 on linux_amd64 azurerm v1.1.5
As the Key Vault secret gets created, I tried to import the resource using the secret identifier. But I get this error message:
│ Error: Cannot import non-existent remote object
│
│ While attempting to import an existing object to "azurerm_key_vault_secret.connection-string", the provider detected that no object exists with the given id. Only pre-existing objects
│ can be imported; check that the id is correct and that it is associated with the provider's configured region or endpoint, or use "terraform apply" to create a new remote object for
│ this resource.
Other secrets are created without a problem. It seems like the provider is having an issue with special characters.
EDIT: CREATE works sometimes, UPDATE and DELETE don't work
I got the same issue, maybe in different context :
The secret is well created, but provider B do not seem capable to see the resource after creation.
I have a similar issue when the provider subscription differed from keyvault subscription.
Wrong usage :
# Use default credentials subscription <sub-a>
provider "azurerm" {
features {}
}
resource "azurerm_key_vault_secret" "example" {
name = "issue-replication"
value = "test2"
key_vault_id = "/subscriptions/<sub-b>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<kv>"
}
In Terraform logs, you can find the rest call for the wrong subscription <sub-a>
GET /subscriptions/<sub-a>/resources?%24filter=resourceType+eq+%27Microsoft.KeyVault%2Fvaults%27+and+name+eq+%27<kv>%27&%24top=5&api-version=2020-06-01 HTTP/1.1
My workaround (you can also use a provider alias to dedicate keyvault provider):
provider "azurerm" {
features {
subscription_id = "<sub-b>" # Force the subscription to use
}
resource "azurerm_key_vault_secret" "example" {
name = "issue-replication"
value = "test2"
key_vault_id = "/subscriptions/<sub-b>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<kv>"
}
Hope it helps..
Hi I have same issue
Error: Provider produced inconsistent result after apply
│
│ When applying changes to azurerm_key_vault_secret.vmpassword["vm3"], provider "provider[\"registry.terraform.io/hashicorp/azurerm\"]" produced an unexpected new value: Root resource was present, but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
==================== Terraform v1.1.7 on windows_386
Hello,
I'm experiencing the same issue after switching to AzureRM v3.x (v3.13.0)
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to azurerm_key_vault_secret.slack_token, provider
│ "provider[\"registry.terraform.io/hashicorp/azurerm\"]" produced an
│ unexpected new value: Root resource was present, but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵
Terraform and providers:
❯ terraform version
Terraform v1.2.4
on darwin_amd64
+ provider registry.terraform.io/articulate/validation v0.0.3
+ provider registry.terraform.io/gavinbunney/kubectl v1.14.0
+ provider registry.terraform.io/hashicorp/azurerm v3.13.0
+ provider registry.terraform.io/hashicorp/helm v2.6.0
+ provider registry.terraform.io/hashicorp/http v2.2.0
+ provider registry.terraform.io/hashicorp/kubernetes v2.12.1
+ provider registry.terraform.io/hashicorp/null v3.1.1
+ provider registry.terraform.io/hashicorp/random v3.2.0
+ provider registry.terraform.io/hashicorp/template v2.2.0
+ provider registry.terraform.io/hashicorp/time v0.7.2
+ provider registry.terraform.io/hashicorp/tls v3.4.0
Hello,
I'm also experiencing this issue with Terraform 1.3.3 and AzureRM provider 3.29.1. The secret is always created correctly but doesn't make it into the state file, which causes problems if we just run it again as it then complains that the resource already exists.
seeing exact same behaviour with azurerm provider v3.32.
Secrets get created in key vault but do not make it to the state with Provider produced inconsistent result after apply
... Provider produced an unexpected new value: Root resource was present, but now absent.
It mostly runs on a second try if we delete (and purge) the secrets beforehand.
Still happening on azurerm v3.57.0
:(
After three iterations of manually deleting & purging the secrets it worked...
Importing of the kv secrets did not work with error: Error: Cannot import non-existent remote object
Same error happening on azurerm v4.3.0
:(
But the good news is re-running plan + apply works, can see a new version of key vault secret is updated
Terraform (and AzureRM Provider) Version
Terraform v1.1.4 on linux_amd64 and Terraform v1.1.5 on linux_amd64
Affected Resource(s)
azurerm_key_vault_secret
Terraform Configuration Files
Panic Output
│ Error: Provider produced inconsistent result after apply │ │ When applying changes to │ module.AzKeyvault.azurerm_key_vault_secret.AppInsight-ConnectionString, │ provider "provider[\"registry.terraform.io/hashicorp/azurerm\"]" produced │ an unexpected new value: Root resource was present, but now absent. │ │ This is a bug in the provider, which should be reported in the provider's │ own issue tracker.
Important Factoids
Note even after having this message all (32)secrets are created on the keyvault