Terraform 0.13 downloading wrong version of provider #25819

nathankodilla · 2020-08-12T13:30:11Z

Terraform Version

0.13.0

Terraform Configuration Files

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "2.62.0"
    }
  }
  required_version = ">= 0.13"
}

terraform {
  backend "s3" {
    bucket = "xxxxxxxxxxxxxxxxxx"
    key    = "xxxxxxxxxxxxxx"
    region = "us-east-1"
    dynamodb_table = "xxxxxxxxxxxxxxxxxxx"
    role_arn = "arn:aws:iam::xxxxxxxxxxx"
  }
}

provider "aws" {
  allowed_account_ids = ["xxxxxxxxxx"]
  assume_role {
    role_arn = "arn:aws:iam::xxxxxxxxxx"
  }
  region     = "us-east-1"
  version = "~> 2.62.0"
}

Expected Behavior

Terraform will only download version 2.62.0 of aws provider.

Actual Behavior

Terraform downloaded version 2.62.0 and 3.1.0 of aws provider.

- terraform.io/builtin/terraform is built in to Terraform
- Finding latest version of -/aws...
- Finding hashicorp/aws versions matching "~> 2.70.0"...
- Installing hashicorp/aws v2.62.0...
- Installed hashicorp/aws v2.62.0 (signed by HashiCorp)
- Installing -/aws v3.1.0...
- Installed -/aws v3.1.0 (signed by HashiCorp)

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, we recommend adding version constraints in a required_providers block
in your configuration, with the constraint strings suggested below.

* -/aws: version = "~> 3.1.0"

This then causes an issue when I run terraform apply where it shows it can't decode a field (issue described here: #25752).

Steps to Reproduce

terraform 0.13upgrade
terraform init

The text was updated successfully, but these errors were encountered:

Luwdo · 2020-08-12T14:39:01Z

Without the required_providers version set call it does only download the 3.1.0 version, but this would defiantly break if you plan to use an older provider with 0.13.0. It is possible that the 2.62 provider is not compatible with 0.13.0 and its not marked as an incompatibility in the provider dependency tree.

Is it possible to confirm that the 3.1 provider is actually being used with terraform calls even when your version constraint should prevent that?

brenak · 2020-08-12T15:19:41Z

Removing my comments, the proper fix is listed below by alisdair and kstromeiraos

kstromeiraos · 2020-08-12T15:21:46Z

This command fixed it for me:

terraform state replace-provider -- -/aws hashicorp/aws

alisdair · 2020-08-12T15:24:08Z

Explanation & Workaround

The source of the -/aws provider qualified name is your state file. You can verify this by running terraform providers.

Running terraform apply (with a no-change plan) should upgrade the state file, leaving you with only the hashicorp/aws provider required. Please give that a try.

If for some reason you cannot run terraform apply, you can update the providers in your state file using terraform state replace-provider -- -/aws hashicorp/aws.

All that said, this is not ideal behaviour, and if we could fix it by somehow merging the provider requirements for legacy providers before attempting installation, I think that would be a better user experience.

Reproduction

Create main.tf:

provider "null" {
  version = "2.1.0"
}

resource "null_resource" "none" { }

terraform-0.12.29 init && terraform-0.12.29 apply -auto-approve
terraform-0.13.0 init

Expected: only version 2.1.0 of null provider is installed
Actual: both 2.1.0 and 2.1.2 are installed

akindo · 2020-08-18T09:44:05Z

Explanation & Workaround

The source of the -/aws provider qualified name is your state file. You can verify this by running terraform providers.

Running terraform apply (with a no-change plan) should upgrade the state file, leaving you with only the hashicorp/aws provider required. Please give that a try.

If for some reason you cannot run terraform apply, you can update the providers in your state file using terraform state replace-provider -- -/aws hashicorp/aws.

All that said, this is not ideal behaviour, and if we could fix it by somehow merging the provider requirements for legacy providers before attempting installation, I think that would be a better user experience.

Reproduction
1. Create main.tf:
   ```terraform
   provider "null" {
     version = "2.1.0"
   }
   
   resource "null_resource" "none" { }
   ```

2. `terraform-0.12.29 init && terraform-0.12.29 apply -auto-approve`

3. `terraform-0.13.0 init`


* Expected: only version 2.1.0 of null provider is installed

* Actual: both 2.1.0 and 2.1.2 are installed

Yes, I believe some of us can't run terraform apply after upgrading to v. 0.13 and running terraform 0.13upgrade, as our code isn't compatible with the latest version (3.2.0) of the AWS provider (#25752), which the state is using. E. g. I got

$ terraform apply                                                     

Error: Invalid resource instance data in state

  on ../../modules/session-manager/main.tf line 63:
  63: resource "aws_iam_instance_profile" "session_manager_ec2" {

Instance module.session-manager.aws_iam_instance_profile.session_manager_ec2
data could not be decoded from the state: unsupported attribute "roles".

One doesn't expect that the code must be compatible with AWS provider v. 3.2.0 when the code is still specifying v. 2.x. Perhaps make terraform state replace-provider -- -/aws hashicorp/aws part of terraform 0.13upgrade?

remilapeyre · 2020-08-18T10:23:03Z

Perhaps make terraform state replace-provider -- -/aws hashicorp/aws part of terraform 0.13upgrade?

I don't think this is possible because the terraform 0.13upgrade changes the configuration code and does not modify the remote state. You will have to run it once per project. On the other hand, if you have multiple deployments of your project, e.g. when using Terraform workspaces, you will have to replace the providers in each of them, running terraform state replace-provider -- -/aws hashicorp/aws for each workspace.

mohsinhijazee · 2020-08-19T11:07:18Z

This command fixed it for me:
terraform state replace-provider -- -/aws hashicorp/aws

This is another of the issue that is happening and for me, this worked:

terraform state replace-provider registry.terraform.io/-/aws registry.terraform.io/hashicorp/aws
terraform state replace-provider registry.terraform.io/-/template registry.terraform.io/hashicorp/template

Again, this should be handled with terraform 0.13upgrade (which does only source code rewrite) or should be a subcommand of the state command.

dudicoco · 2021-01-20T15:21:41Z

Can this be added to the 0.13 upgrade docs please? We've been trying to figure this out for hours.
Also the workaround terraform state replace-provider -- -/aws hashicorp/aws is not ideal as we have hundreds of directories, each with different providers.
Can you provide us with a more ideal fix please?
Thanks

dudicoco · 2021-01-20T16:42:13Z

@alisdair I've tried your suggestion from #25957:

You can temporarily duplicate the hashicorp folder of your local provider mirror to -. That is, you'd have a directory /usr/lib/plugins/registry.terraform.io/-/aws/3.0.0/linux_amd64 with the same contents as the hashicorp/aws/… directory. This will allow you to run terraform apply (with no changes) to migrate the state file.

This did not work for me, the latest version is still being downloaded:

Initializing provider plugins...
- Finding hashicorp/aws versions matching "2.53.0, ~> 2.53"...
- Finding latest version of -/aws...
- Installing hashicorp/aws v2.53.0...
- Installed hashicorp/aws v2.53.0 (signed by HashiCorp)
- Installing -/aws v3.24.1...
- Installed -/aws v3.24.1 (signed by HashiCorp)

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, we recommend adding version constraints in a required_providers block
in your configuration, with the constraint strings suggested below.

* -/aws: version = "~> 3.24.1"

Any suggestions?
Thanks

dudicoco · 2021-01-26T08:41:11Z

@alisdair can you please advise regarding my comment above?

alisdair · 2021-01-26T14:32:38Z

The suggestion from the other issue was specific to that reporter's situation, which doesn't seem to match yours. The best way forward here is to use the state replace-provider command to replace the providers in state which are causing the upgrade to fail.

virtualdom · 2021-02-08T21:00:37Z

Hi! I've already run state replace-provider, yet I notice that the wrong provider is still being installed

provider "aws" {
  region = var.aws_region
}

terraform {
  required_version = "0.13.6"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "2.49.0"
    }
  }

  backend "s3" {}
}

$ terraform state replace-provider registry.terraform.io/-/aws registry.terraform.io/hashicorp/aws
No matching resources found.

$ terraform init
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- terraform.io/builtin/terraform is built in to Terraform
- Finding latest version of -/template...
- Finding hashicorp/aws versions matching "3.0.0"...
- Finding latest version of -/aws...
- Installing -/template v2.2.0...
- Installed -/template v2.2.0 (signed by HashiCorp)
- Installing hashicorp/aws v3.0.0...
- Installed hashicorp/aws v3.0.0 (signed by HashiCorp)
- Installing -/aws v3.27.0...
- Installed -/aws v3.27.0 (signed by HashiCorp)

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, we recommend adding version constraints in a required_providers block
in your configuration, with the constraint strings suggested below.

* -/aws: version = "~> 3.27.0"
* -/template: version = "~> 2.2.0"

A plan/apply still executes without an error, but can I be sure that the specified version of hashicorp/aws is being used instead of the version for -/aws?

alisdair · 2021-02-08T21:29:18Z

For anyone still encountering this problem after running terraform state replace-provider, I recommend using terraform providers to find out where the requirement for legacy providers is coming from. This may be an external module which needs to be upgraded to support Terraform 0.13+.

virtualdom · 2021-02-08T21:34:51Z

For anyone still encountering this problem after running terraform state replace-provider, I recommend using terraform providers to find out where the requirement for legacy providers is coming from. This may be an external module which needs to be upgraded to support Terraform 0.13+.

Unfortunately, I had tried this as well 😞 not sure if there's something I'm missing re: my output.

$ terraform providers

Providers required by configuration:
.
├── provider[registry.terraform.io/hashicorp/aws] 2.49.0
└── provider[terraform.io/builtin/terraform]

Providers required by state:

    provider[registry.terraform.io/hashicorp/aws]

    provider[terraform.io/builtin/terraform]

alisdair · 2021-02-08T21:39:03Z

@virtualdom Huh! I can't imagine what could have caused this combination of errors—where could the requirement for -/template be coming from?

So far, it doesn't seem like it's the same problem as this issue, so if you can reliably reproduce it with a small configuration, we'd like to hear more in a new issue. If not, you may find some help on the community forum.

reschenburgIDBS · 2021-04-09T09:51:28Z

random question on this topic.. is it possible that the S3 backend configuration for example uses an internal provider setting somewhere?

I've tried to run terraform state replace provider but only keep getting No matching resources found.

terraform provider shows:

Providers required by configuration:
.
├── provider[registry.terraform.io/hashicorp/aws] ~> 3.27.0, ~> 3.27.0
├── provider[registry.terraform.io/hashicorp/template] >= 2.2.0

Providers required by state:

    provider[registry.terraform.io/-/aws]

I've manually checked the state file - there is no reference to -/aws at all, yet it is downloaded every time I terraform init (or our CI does).

If I remember this module correctly, we started out on terraform 0.12.30 - and then upgraded at some point to 0.13.6 - I'm wondering if the S3 backend config uses the -/aws provider still from when we first initialised the backend under 0.12.30?

Anybody got any experience with that or any idea where this setting might be? Our CI spins up a fresh terraform 0.13.6 container, does a fresh repo checkout, tf init, tf plan, tf apply every time it runs, so it's something that I would have thought comes out of the state somewhere, but can't find it.

It's not a major issues as I now know that our modules use the correct pinned hashicorp/aws provider version, but it's confusing and annoying to anybody who hasn't gone down this rabbit hole..

apparentlymart · 2022-09-28T19:27:05Z

Hi all!

Terraform v0.13 is pretty old by now so I don't expect we'll be making any further changes to that line of releases. Some folks above suggested documenting terraform state replace-provider as an explicit way to avoid installing the legacy providers and so at some point we added a section to the upgrade guide about that, which captures the same workaround that was discussed in the comments above.

Because the v0.13 series is closed to new development, and because terraform 0.13upgrade is not present in any later release, I'm going to close this issue now. Thanks for sharing the workarounds!

github-actions · 2022-10-29T02:33:33Z

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

nathankodilla added bug new new issue not yet triaged labels Aug 12, 2020

alisdair added explained a Terraform Core team member has described the root cause of this issue in code v0.13 Issues (primarily bugs) reported against v0.13 releases and removed new new issue not yet triaged labels Aug 12, 2020

mukta-puri mentioned this issue Aug 18, 2020

Provider Removed Attributes Causing "data could not be decoded from the state: unsupported attribute" Error #25752

Closed

alisdair mentioned this issue Aug 24, 2020

Failed to query available provider packages (aws) #25957

Closed

DaemonDude23 mentioned this issue Aug 24, 2020

Error: Instance data.aws_region.current data could not be decoded from the state unsupported attribute "current hashicorp/terraform-provider-aws#14763

Closed

Naragorn mentioned this issue Aug 25, 2020

Terraform init downloading wrong aws provider version #25987

Closed

riechst1 mentioned this issue Aug 19, 2022

Terraform fails to parse the version from the registry cloudamqp/terraform-provider-cloudamqp#167

Closed

apparentlymart closed this as not planned Won't fix, can't repro, duplicate, stale Sep 28, 2022

github-actions bot locked as resolved and limited conversation to collaborators Oct 29, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Terraform 0.13 downloading wrong version of provider #25819

Terraform 0.13 downloading wrong version of provider #25819

nathankodilla commented Aug 12, 2020 •

edited

Loading

Luwdo commented Aug 12, 2020 •

edited

Loading

brenak commented Aug 12, 2020 •

edited

Loading

kstromeiraos commented Aug 12, 2020

alisdair commented Aug 12, 2020

akindo commented Aug 18, 2020 •

edited

Loading

Explanation & Workaround

Reproduction

remilapeyre commented Aug 18, 2020

mohsinhijazee commented Aug 19, 2020

dudicoco commented Jan 20, 2021

dudicoco commented Jan 20, 2021 •

edited

Loading

dudicoco commented Jan 26, 2021

alisdair commented Jan 26, 2021

virtualdom commented Feb 8, 2021

alisdair commented Feb 8, 2021

virtualdom commented Feb 8, 2021

alisdair commented Feb 8, 2021

reschenburgIDBS commented Apr 9, 2021

apparentlymart commented Sep 28, 2022

github-actions bot commented Oct 29, 2022

Terraform 0.13 downloading wrong version of provider #25819

Terraform 0.13 downloading wrong version of provider #25819

Comments

nathankodilla commented Aug 12, 2020 • edited Loading

Terraform Version

Terraform Configuration Files

Expected Behavior

Actual Behavior

Steps to Reproduce

Luwdo commented Aug 12, 2020 • edited Loading

brenak commented Aug 12, 2020 • edited Loading

kstromeiraos commented Aug 12, 2020

alisdair commented Aug 12, 2020

Explanation & Workaround

Reproduction

akindo commented Aug 18, 2020 • edited Loading

Explanation & Workaround

Reproduction

remilapeyre commented Aug 18, 2020

mohsinhijazee commented Aug 19, 2020

dudicoco commented Jan 20, 2021

dudicoco commented Jan 20, 2021 • edited Loading

dudicoco commented Jan 26, 2021

alisdair commented Jan 26, 2021

virtualdom commented Feb 8, 2021

alisdair commented Feb 8, 2021

virtualdom commented Feb 8, 2021

alisdair commented Feb 8, 2021

reschenburgIDBS commented Apr 9, 2021

apparentlymart commented Sep 28, 2022

github-actions bot commented Oct 29, 2022

nathankodilla commented Aug 12, 2020 •

edited

Loading

Luwdo commented Aug 12, 2020 •

edited

Loading

brenak commented Aug 12, 2020 •

edited

Loading

akindo commented Aug 18, 2020 •

edited

Loading

dudicoco commented Jan 20, 2021 •

edited

Loading