Open raffato opened 2 years ago
Thanks for the issue report. Verified that the "Required plugins are not installed" error happens if you have a lockfile with providers from a non-matching architecture, then run terraform providers
. It does seem that we can do better than this error and should be able to output a list of providers even in this case.
If you delete the lockfile, terraform providers
will give the output you describe in the proposal, distinguishing between providers required by config and providers required by state. Is this a suitable workaround for your issue?
Tagged as bug because I think we can fix the output of terraform providers
and make it more helpful in such cases.
Yes, indeed it was an original design goal for terraform providers
to make a best effort to describe the situation even if it's currently not totally valid, because it's primary purpose is to help with debugging problems like this.
It looks like when we later retrofitted the dependency lock file it introduced some new error cases we didn't know to expect when originally implementing that command, and so it currently fails on those. I think we should be able to make it more resilient so that e.g. if it detects any problems related to the provider cache consistency with the lock file it will still proceed as if there had been no lock file at all, and then emit the error diagnostics only after it's displayed the subset of information it was able to determine.
Wasted a good amount of time today because grepping repo returned no results for pulling in the problem dependency. Turned out terraform providers
has a section Providers required by state:
that gives me the root of the problem.
This has to do with hashicorp/template
in my case.
I think the situation has changed a little since this issue was opened, but I don't think it's fully fixed.
What's changed is that the terraform init
messaging should now recommend to run terraform providers
to see where all of the dependencies are coming from.
However, I don't think we've yet made any changes to avoid terraform providers
from failing when the lock file is inconsistent with the cache. I suggest that we consider this issue to represent that bug, and therefore it's fixed once we're sure that terraform providers
can always produce at least a partial result even if the provider cache directory is incomplete or the lock file is somehow invalid.
I think there is a broader question here about whether it would be viable to ignore data resources in the state when deciding what the state depends on. I don't think we'll be able to address that here because it's a more invasive thing to change, but it is interesting to note that installin providers for data resources that only exist in the state is only in service of some relatively unimportant situations:
terraform console
allows referring to data resource instances read on the previous runterraform show
shows on-screen the result of data resource instances read on the previous runIn particular, terraform apply
(and terraform plan
) don't need to involve a provider to deal with a data resource that has been removed from the configuration already, because the only reasonable action in that case is to remove the stale object from the state entirely and Terraform Core can just do that itself without any need to inspect the provider-specific result data.
I wonder about somehow loosening the design requirements for terraform console
and terraform show
so that they can be permitted to just assume any data resource that isn't in the configuration doesn't exist at all, even if it does happen to still exist in the state. It seems relatively unlikely that someone would really need to look at the stale previous result from a data resource they've now removed, but that's just a hunch on my part.
I don't think we should block on resolving this question in order to fix the terraform providers
bug, but it would be nice to avoid this problem in the first place by not even trying to install the hashicorp/template
provider once all of data
blocks using it are removed from the configuration.
Current Terraform Version
1.2.1
Use-cases
My company uses Apple and most of my team now have M1 Macbooks. I try to run
terraform init
but the codebase has 50+ instances ofdata "template_file"...
. Fixing this seems to be straight-forward - replacetemplate_file
data sources withtemplatefile()
functions. But when I'm done,terraform init
still fails because "something" still wants the template provider. I try to runterraform providers
to identify what requires it, but this fails without giving any helpful information because the provider is missing. Duh! I wonder if sub-modules require it, so I unpin all module versions, butterraform init
still fails with this kinda useless message:TF_LOG=TRACE generates a ton of text but nothing that points to a root cause. After cursing Terraform for a day, the next morning (showerthoughs) it dawns on me that Terraform needs the provider because the current state references it. But I have to guess this because I can't run
terraform providers
.Attempted Solutions
Tried to run
terraform providers
but it fails with this error:Proposal
terraform providers
to provide partial information! Surely it knows which providers are currently required, even if they're not installed? Should it not simply flag that it doesn't have specific version information becauseterraform init
is required, instead of bailing out and providing nothing?terraform init
error message. For example, a much more useful error message could look like this:References
https://github.com/hashicorp/terraform/issues/29993#issuecomment-1023787499