Terraform v0.13.1
+ provider registry.terraform.io/hashicorp/vault v2.13.0
terraform {
required_version = ">= 0.13"
backend "s3" {}
required_providers {
vault = {
source = "hashicorp/vault"
version = "~> 2.13.0"
}
}
}
provider "vault" {
address = var.address
token = var.token
}
terraform allows provider versions referenced in state to be modified by newer providers in newer versions of code
, [2020-09-02T18:23:47.253410 #1] INFO -- Tf: sh: cmd=[terraform init -backend-config "profile=abc-mgmt-tf" -backend-config "bucket=abc-mgmt-tf-state" -backend-config "key=abc-tf-vault-tenant-arme.tfstate" -backend-config "dynamodb_table=tf-state-lock" -backend-config "encrypt=true" -backend-config "skip_metadata_api_check=true"], is-echo=true
Initializing modules...
- tenant in modules/vault/tenant
Initializing the backend...
Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
Initializing provider plugins...
- Finding hashicorp/vault versions matching "~> 2.10"...
- Installing hashicorp/vault v2.13.0...
- Installed hashicorp/vault v2.13.0 (signed by HashiCorp)
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
I, [2020-09-02T18:23:51.224913 #1] INFO -- Tf: sh: cmd=[terraform plan -out tf.out], is-echo=true
rake aborted!
cmd=[terraform plan -out tf.out] failed with status=[pid 75 exit 1]
/rake/module/util.rb:74:in `sh'
/rake/Rakefile:62:in `block (3 levels) in <top (required)>'
/rake/module/util.rb:27:in `inDir'
/rake/Rakefile:61:in `block (2 levels) in <top (required)>'
Tasks: TOP => tf:thru_plan => tf:plan
(See full trace by running task with --trace)
Error: Could not load plugin
Plugin reinitialization required. Please run "terraform init".
Plugins are external binaries that Terraform uses to access and manipulate
resources. The configuration provided requires plugins which can't be located,
don't satisfy the version constraints, or are otherwise incompatible.
Terraform automatically discovers provider requirements from your
configuration, including providers used in child modules. To see the
requirements and constraints, run "terraform providers".
Failed to instantiate provider "registry.terraform.io/-/vault" to obtain
schema: unknown provider "registry.terraform.io/-/vault"
I, [2020-09-02T18:29:12.614828 #1] INFO -- Tf: sh: cmd=[terraform providers], is-echo=true
Providers required by configuration:
.
├── provider[registry.terraform.io/hashicorp/vault] ~> 2.10
└── module.tenant
└── provider[registry.terraform.io/hashicorp/vault]
Providers required by state:
provider[registry.terraform.io/-/vault]
__update__: replace-provider seemed to do the trick, is this the appropriate action for this situation?
terraform state replace-provider -auto-approve registry.terraform.io/-/vault registry.terraform.io/hashicorp/vault
Hi @tony-kerz! Sorry for this odd behavior and thanks for reporting it.
The terraform state replace-provider
command is indeed the workaround I was going to suggest, and if that works for you then that should be fine to move on.
What seems odd here, and perhaps worthy of some more attention even though you've found a workaround, is that we expect terraform init
to detect and install this legacy -/vault
provider one time as part of the upgrade process, which would then normally allow the next terraform apply
to implicitly do what that terraform state replace-provider
command does and thus remove the last remant of -/vault
so it'll no longer be needed on future terraform init
.
In your case it seems like terraform init
didn't try to install -/vault
at all, which I think is unexpected. That then in turn left terraform plan
in the awkward position of not having a provider that is clearly indicated in the state (which we can see in your terraform providers
output).
I don't believe we've seen this particular situation -- where terraform init
doesn't even attempt to install the legacy provider -- before. I wasn't able to quickly reproduce it with a similar configuration I constructed locally, but that doesn't really surprise me because I don't have your exact state snapshot and so my situation is expectedly different. If you're able to share it, it would be helpful to see the full log output that terraform init
produces when you run it with the TF_LOG=trace
environment variable set, because the trace logs include some more details about Terraform's process of deciding which providers it needs to install and what happened when it tried to install them.
See https://github.com/terraform-providers/terraform-provider-tfe/issues/209 and https://github.com/hashicorp/terraform/issues/26075 for additional examples.
I ran into the same problem with a provider registry.terraform.io/hashicorp/null
. This provider already has a file path in registry.terraform.io/hashicorp
, so the aforementioned workaround is not applicable for me :-/
Error: Could not load plugin
Plugin reinitialization required. Please run "terraform init".
Plugins are external binaries that Terraform uses to access and manipulate
resources. The configuration provided requires plugins which can't be located,
don't satisfy the version constraints, or are otherwise incompatible.
Terraform automatically discovers provider requirements from your
configuration, including providers used in child modules. To see the
requirements and constraints, run "terraform providers".
Failed to instantiate provider "registry.terraform.io/hashicorp/null" to
obtain schema: unknown provider "registry.terraform.io/hashicorp/null"
I have the same with aws and archive providers. I can't provide full trace logs but maybe these can help
Interesting also that after I used the replace-providers with successful planning, sequential planning and apply didn't found "matching provider" for the one with '-'
```
2020/09/24 17:51:47 [TRACE] providercache.fillMetaCache: scanning directory .terraform/plugins
2020/09/24 17:51:47 [TRACE] getproviders.SearchLocalDirectory: failed to resolve symlinks for .terraform/plugins: lstat .terraform/plugins: no such file or directory
2020/09/24 17:51:47 [TRACE] providercache.fillMetaCache: error while scanning directory .terraform/plugins: cannot search .terraform/plugins: lstat .terraform/plugins: no such file or directory
2020/09/24 17:51:47 [WARN] Failed to scan provider cache directory .terraform/plugins: cannot search .terraform/plugins: lstat .terraform/plugins: no such file or directory
2020/09/24 17:51:47 [DEBUG] Service discovery for registry.terraform.io at https://registry.terraform.io/.well-known/terraform.json
2020/09/24 17:51:47 [TRACE] HTTP client GET request to https://registry.terraform.io/.well-known/terraform.json
Initializing provider plugins...
I'm seeing the same thing with the azurerm provider.
Terraform v0.13.4
Initializing plugins and modules...
Error: Could not load plugin
Plugin reinitialization required. Please run "terraform init".
Plugins are external binaries that Terraform uses to access and manipulate
resources. The configuration provided requires plugins which can't be located,
don't satisfy the version constraints, or are otherwise incompatible.
Terraform automatically discovers provider requirements from your
configuration, including providers used in child modules. To see the
requirements and constraints, run "terraform providers".
Failed to instantiate provider "registry.terraform.io/-/azurerm" to obtain
schema: unknown provider "registry.terraform.io/-/azurerm"
update: replace-provider seemed to do the trick, is this the appropriate action for this situation?
terraform state replace-provider -auto-approve registry.terraform.io/-/vault registry.terraform.io/hashicorp/vault
Thanks @tony-kerz, this workaround working for me
terraform state replace-provider
probably fix this, but when you've more than 100 state isn't a valid solution ...
Dropping this here in case it can help in further troubleshooting or workarounds. The replace-provider
workaround didn't work for me since we are using Terraform Cloud. Sort of a stab in the air, I changed the source
from "hashicorp/aws"
to -/aws
:
terraform {
required_version = ">= 0.13"
required_providers {
aws = {
source = "-/aws"
}
}
This dropped a mysterious error in the plan output:
Error: Missing required argument
The argument "region" is required, but was not set.
So I reverted the change and then the next plan and apply worked without error.
I should have expected this, but my "workaround" didn't work on another workspace with the same defect.
OK, total face palm moment. Not only was I wrong about replace-provider
not working with TFC. (See here) but my supposed workaround was, most likely, due to my use of the replace-provider
command.
Hopefully some day this will all be less mysterious to me.
I am facing similar issue while running terraform init.
error comes.:
Error: Failed to install provider
Error while installing hashicorp/archive v2.0.0: open
.terraform\plugins\registry.terraform.io\hashicorp\archive\2.0.0\windows_amd64\terraform-provider-archive_v2.0.0_x5.exe:
The system cannot find the path specified.
facing similar kind of issue while running terraform init command.
terraform {
required_version = "0.13.2"
backend "remote" {
hostname = "terraform.xxxx.com"
organization = "xxxxxxxx"
workspaces {
name = "xxxxxx"
}
}
required_providers {
aws = {
source = "hashicorp/aws"
version = "3.15.0"
}
}
}
provider "aws" {}
Error: Failed to install provider
.terraform\plugins\registry.terraform.io\hashicorp\archive\2.0.0\windows_amd64\terraform-provider-archive_v2.0.0_x5.exe:
The system cannot find the path specified.
I think I've managed to figure out what's going on here. This can only happen when using workspaces. When I cleared my .terraform
dir and ran terraform init
, it was on the default
workspace, which has an empty state. When I switched to the desired workspace and ran terraform init
again, it now downloads the compatibility -/whatever
providers, and then everything works.
@agaffney Thanks, this worked for me.
Manually running the replace-provider
command on each state/workspace was not a viable option for us so just adding an extra init
step after selecting the workspace in our Jenkins pipelines allowed for an automated path forward.
I can confirm that @agaffney's fix worked for me as well. I was having the exact same issue with the Azurerm provider. The double init did the trick. Thanks!
Most helpful comment
__update__: replace-provider seemed to do the trick, is this the appropriate action for this situation?