Plugin issues: No provider "aws" plugins meet the constraint

[stevenyongzion]

I am handling an slightly old terraform project using terraform 0.12.29

% terraform version
Terraform v0.12.29

When running terraform init, I got this error:

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "okta" (terraform-providers/okta) 3.10.1...
- Downloading plugin for provider "null" (hashicorp/null) 3.1.0...
- Downloading plugin for provider "template" (hashicorp/template) 2.2.0...
- Downloading plugin for provider "tls" (hashicorp/tls) 3.1.0...
- Downloading plugin for provider "datadog" (terraform-providers/datadog) 2.22.0...
- Downloading plugin for provider "archive" (hashicorp/archive) 2.1.0...

No provider "aws" plugins meet the constraint "2.53.0,2.53.0,2.53.0,2.53.0,2.53.0,2.53.0,2.53.0,>= 2.65,>= 2.70,~> 2.35,~> 2.35,~> 2.35,~> 2.35,~> 2.35,~> 2.35".

The version constraint is derived from the "version" argument within the
provider "aws" block in configuration. Child modules may also apply
provider version constraints. To view the provider versions requested by each
module in the current configuration, run "terraform providers".

To proceed, the version constraints for this provider must be relaxed by
either adjusting or removing the "version" argument in the provider blocks
throughout the configuration.

- Downloading plugin for provider "dns" (hashicorp/dns) 3.1.0...

Below is my provider AWS:

provider "aws" {
  shared_credentials_file = "~/.aws/credentials"
  profile                 = "management-admin"
  region                  = var.region
  alias                   = "management"
  version                 = "2.53.0"
}

The error does not actually make sense to me. I tried changing the version 2.53.0 to newer version and each time different pluggin would then throw the same error.

I tried terraform init -upgrade as well but still the same.

What would have cause this and what are my options.

[stuart-c]

In the current situation Terraform cannot operate as the version constraints for the AWS provider are impossible to achieve.

Some things are saying it needs exactly version 2.53.0, others at least 2.65 or 2.70 and yet others want 2.35.X

It isn’t possible to do so.

To fix you would need to change some of those requirements - for example by adjusting the modules to all work with 2.70 or later.

If you aren’t already doing so I would strongly recommend ensuring that all modules are version pinned (either to specific versions or allowing minor/patch adjustments via the ~> mechanism) so you don’t get updates unless you are expecting them.

I’d also suggest using a tool such as Renovate or Dependabot to help manage dependency version bumps.

[apparentlymart]

As @stuart-c suggested, Terraform requires that all modules in your configuration must agree on a single version of each provider to use, because in Terraform providers are a configuration-global idea, not a module-specific idea. (Typically providers are configured only in the root module and then are either inherited by or passed to child modules, and so all modules must agree in order for that mechanism to work.)

For versions of Terraform prior to v0.14 (which has introduced a different approach using an automatically-maintained lock file) we recommended using different styles of version constraints for root modules vs. shared modules:

• For root modules, use either exact constraints like 2.53.0 or “pessimistic” constraints like ~> 2.53.0 to set both a lower and an upper limit for which version your whole configuration can select.
• For shared modules, use only >= constraints to set the minimum version a module requires, unless you happen to know that it’s already incompatible with newer versions of the provider due to already-published breaking changes.

The reason for these guidelines is to avoid the sort of problem you’ve encountered here, where you can get stuck with a mutually-incompatible set of version constraints across all of your modules.

To move forward from where you are, I’d start by running the command terraform providers, which should tell you which version constraint each module in your configuration has set. Using that information, I’d suggest working through each module in turn and making them follow the guidelines I described above, to eventually reach a situation where only the root module is setting an upper bound and the other modules are only setting a lower bound, and therefore Terraform should be able to find a version that all of the modules are compatible with.

In the presence of breaking changes (usually indicated by major releases) it might be the case that there is no suitable solution, because modules are written against different mutually-incompatible versions, but that doesn’t seem to be the case for you because all of your AWS provider version constraints are within the 2.x.x series and therefore the later ones should be broadly backward compatible with the earlier ones.

---

You’re using Terraform v0.12 so the following won’t apply until you’re able to upgrade, but I also wanted to say a little about Terraform v0.14 and later in case other folks find this answer when encountering similar problems.

Terraform v0.14 introduced the dependency lock file which achieves a separation between the version constraints (specifying which versions a module is compatible with) from the version selections (specifying which exact versions a particular configuration as a whole is currently using).

For codebases that have a lock file checked in to version control, the earlier advice I mentioned above changes to the following simpler rule: for all modules, including root modules, start by specifying only lower constraint bounds, like >= 2.53.0 if your module relies on features introduced in version 2.53.0, and let the dependency lock file be the mechanism to avoid implicitly upgrading to a newer version. Then occasionally, at a convenient time for you, you can run terraform init -upgrade to see if newer versions are available and test them against your existing modules and commit the new lock file changes if you find the new versions compatible with your modules.

There’s more detail on what I’ve said in this appendix in the current (at the time I write this) version of the Provider Requirements documentation.

[stevenyongzion]

Thanks guys. Taking shortcuts, I ended up copying the .terraform folder from 1 of my peers. I cannot simply take any as some of them use Mac and some use Windows. Plugins downloaded are specifics to platform of your laptop.

[apparentlymart]

Thanks for adding that followup, @stevenyongzion.

I would expect that in newer Terraform versions this wouldn’t have been a problem because the plugin cache in .terraform is now treated as actually a cache rather than as an authority, and so terraform init would now notice that you don’t have the necessary plugins for your current platform and install them as if the cache directory had been empty.

However, from my memory of how plugin installation worked in v0.12 I can believe that doing this on that version would create some odd behaviors. In general we don’t expect folks to copy or move .terraform directories between systems or between working directories on the same system, and so the changes in later versions were not intended to make that work better but rather just happened to make this work better as a side-effect of other improvements.

That particular error message is an odd way for Terraform to report that problem, but I think what happened here is that Terraform saw that there was already a package for some version of the aws provider in .terraform and so, because that version treated .terraform in the same way as a local mirror directory, it assumed that you would want to use the version you already had installed instead of a new one from upstream. But then, as you saw, it didn’t actually work out in practice because the installer tried to enumerate which versions were available in your local directory and noticed that there were none there suitable for your current platform.