Terraform: panic: terraform.io/builtin/terraform is not a legacy addrs.Provider

[gidesh]

Terraform Version

0.13.0
 terraform.io/builtin/terraform is built in to Terraform
 - Finding latest version of -/google...
 - Finding latest version of -/kubernetes...
 - Finding hashicorp/google versions matching "~> 3.33.0"...
 - Finding hashicorp/kubernetes versions matching "~> 1.11"...
 - Installing hashicorp/google v3.33.0...
 - Installed hashicorp/google v3.33.0 (signed by HashiCorp)
 - Installing hashicorp/kubernetes v1.12.0...
 - Installed hashicorp/kubernetes v1.12.0 (signed by HashiCorp)
 - Installing -/google v3.33.0...
 - Installed -/google v3.33.0 (signed by HashiCorp)
 - Installing -/kubernetes v1.12.0...
 - Installed -/kubernetes v1.12.0 (signed by HashiCorp)

Terraform Configuration Files

...
resource "google_service_account" "gcloud-exporter" {
  account_id   = "gcloud-exporter"
  display_name = "Used by gcloud-exporter to gather non-stackdriver metrics from gcloud"
  project      = var.gcp_project_name
}

Debug Output

Crash Output

https://gist.github.com/jishu11/4bf943606c038a9b4d1aac73bbb09adf

Expected Behavior

We had recently migrated our terraform code from 0.11.14 to 0.12.29. As 0.13.0 is now GA there should have not been an issue upgrading to 0.13.0

Actual Behavior

We had recently migrated our terraform code from 0.11.14 to 0.12.29. As 0.13.0 is now GA we thought of upgrading it.

Running it with 0.13.0 causes terraform to crash when we run it against the code.

data.google_client_config.current: Refreshing state... [id=2020-08-11 10:56:40.151352994 +0000 UTC]
 google_service_account.gcloud-exporter: Refreshing state... [id=projects/jl-platform-k8s-xx/serviceAccounts/[email protected]]
 panic: terraform.io/builtin/terraform is not a legacy addrs.Provider
 goroutine 180 [running]:
 github.com/hashicorp/terraform/addrs.Provider.LegacyString(0xc0016cddd0, 0x9, 0x26c978d, 0x7, 0x26d3cc4, 0xc, 0x0, 0x0)

Steps to Reproduce

1. terraform init -backend-config="verify/backend.tfvars"
2. terraform plan --var-file="verify/tier.tfvars"

Additional Context

It has a datasource which connects to a gcs remote state. The remote state is still on 0.11.14 which is scheduled to be updated at the very end.

data "terraform_remote_state" "cluster" {
  backend   = "gcs"
  workspace = var.cluster_region

  config = {
    bucket = "jl-xxx-verify"
    prefix = "terraform/${var.cluster_type}"
  }
}

terraform init ran successfully

Initializing the backend...
 Successfully configured the backend "gcs"! 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 -/google...
 - Finding latest version of -/kubernetes...
 - Finding hashicorp/google versions matching "~> 3.33.0"...
 - Finding hashicorp/kubernetes versions matching "~> 1.11"...
 - Installing hashicorp/google v3.33.0...
 - Installed hashicorp/google v3.33.0 (signed by HashiCorp)
 - Installing hashicorp/kubernetes v1.12.0...
 - Installed hashicorp/kubernetes v1.12.0 (signed by HashiCorp)
 - Installing -/google v3.33.0...
 - Installed -/google v3.33.0 (signed by HashiCorp)
 - Installing -/kubernetes v1.12.0...
 - Installed -/kubernetes v1.12.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.
 * -/google: version = "~> 3.33.0"
 * -/kubernetes: version = "~> 1.12.0"
 Terraform has been successfully initialized!

References

[philipbohannon]

Had a very similar crash also on 13.0. Here is crash log.

panic: terraform.io/builtin/terraform is not a legacy addrs.Provider
crash.log

[danieldreier]

@philipbohannon are you also using remote state from 0.11.x?

[goedelsoup]

Encountered this as well. In my situation, we had upgraded to 0.12 recently but no modifications were detected so the state was produced from an 0.11.x version. I was able to switch to 0.12.29, pull the state, bump the serial, and push the state. At that point, 0.13 was able to plan but the remote state was still in the flat 0.11 format and I received the error cannot decode dynamic from flatmap. I created a dud module with the same data sources and copied the remote state instances over to resolve.

[dustinneray]

Encountered this as well loading a 0.11.x remote state, I think it's related to the change https://github.com/hashicorp/terraform/commit/7caf0b924644154e6ef8ce4b161c9fee3fd5333f to migrate from the registry.terraform.io terraform provider to the new one which is not in the legacy namespace.

Just adding a special case to the provider.go to skip over the panic in this case seems to be enough to get it working for me but that's probably not the ideal solution.

[alisdair]

Thanks for reporting this! The panic is caused by the state upgrader attempting to convert the builtin terraform provider address to a legacy provider string. This should be fixed in #25861.

If possible, I would recommend upgrading to 0.12.29 and then later 0.13. In my local testing with 0.11 remote state I encountered another bug that I haven't tracked down yet, which 0.12 is not affected by.

[alisdair]

If possible, I would recommend upgrading to 0.12.29 and then later 0.13. In my local testing with 0.11 remote state I encountered another bug that I haven't tracked down yet, which 0.12 is not affected by.

This follow-up issue (#25863) has been closed, as we don't support loading remote state across more than one major version. That is, 0.13 will not be able to reliably load 0.11 remote state directly, and an upgrade path via 0.12 will be required.

[hashibot[bot]]

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.