28
votes

I'm trying to deploy a bitbucket pipeline using terraform v0.14.3 to create resources in google cloud. The pipeline fails with error:

Error: Invalid legacy provider address This configuration or its associated state refers to the unqualified provider "google". You must complete the Terraform 0.13 upgrade process before upgrading to later versions.

We updated our local version of terraform to v.0.13.0 and then ran: terraform 0.13upgrade as referenced in this guide: https://www.terraform.io/upgrade-guides/0-13.html. A versions.tf file was generated requiring terraform version >=0.13 and our required provider block now looks like this:

terraform {
  backend "gcs" {
    bucket      = "some-bucket"
    prefix      = "terraform/state"
    credentials = "key.json" #this is just a bitbucket pipeline variable
  }
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 2.20.0"
    }
  }
}
provider "google" {
  project     = var.project_ID
  credentials = "key.json"
  region      = var.project_region
}

We still get the same error when initiating the bitbucket pipeline. Does anyone know how to get past this error? Thanks in advance.

7

7 Answers

32
votes

Explanation

This is because Terraform only supports upgrades from one major feature upgrade at a time. Most likely the older state file in your case was written with a version earlier than 0.13 version and if you did not run terraform apply with 0.13 version, this error is to be expected because the upgrade to the 0.13 was not complete. It could've been solved had you run it (as explained in above answer).

Solution

  1. At this point (i.e. using terraform 0.14.x) you can use the replace-provider command
terraform state replace-provider "registry.terraform.io/-/google" "hashicorp/google"
  1. Now initialise again and this should take care of installing the provider:
terraform init

More information about the issue can be found here.

11
votes

in our case, we were on aws and had similar error

...

Error: Invalid legacy provider address

This configuration or its associated state refers to the unqualified provider
"aws".

the steps to resolve were to ensure syntax was upgraded by running terraform init again, checking the warnings and finally updating the statefile with following method.

# update provider in state file
terraform state replace-provider -- -/aws hashicorp/aws

# reinit
terraform init

specific of ops problem, if issue still occurs, verify access to the bucket location from local and from pipeline. also verify the version of terraform running in pipeline. depending on configuration it may be the remote statefile is/can not be updated.

6
votes

Same issue for me. I ran:

terraform providers

That gave me:

Providers required by configuration:
registry.terraform.io/hashicorp/google

Providers required by state:
registry.terraform.io/-/google

So I ran:

terraform state replace-provider registry.terraform.io/-/google registry.terraform.io/hashicorp/google

That did the trick.

3
votes

To add on, I had installed terraform 0.14.6 but the state seemed to be stuck in 0.12. In my case I had 3 references that were off, this article helped me pinpoint which ones (all the entries in "Providers required by state" which had a - in the link. https://github.com/hashicorp/terraform/issues/27615 I corrected it by running the replace-provider command for each entry which was off, then running terraform init. I note doing this and running a git diff, the tfstate has been updated and now uses 0.14.x terraform instead of my previous 0.12.x. i.e.

terraform providers

terraform state replace-provider registry.terraform.io/-/azurerm registry.terraform.io/hashicorp/azurerm 
2
votes

my case was like this

Error: Invalid legacy provider address

This configuration or its associated state refers to the unqualified provider
"openstack".

You must complete the Terraform 0.13 upgrade process before upgrading to later
versions.

for resolving the issue

remove the .terraform folder

the execute the following command

terraform state replace-provider -- -/openstack terraform-provider-openstack/openstack

after this command, you will see the below print, enter yes

Terraform will perform the following actions:

  ~ Updating provider:
    - registry.terraform.io/-/openstack
    + registry.terraform.io/terraform-provider-openstack/openstack

Changing 11 resources:

  openstack_compute_servergroup_v2.kubernetes_master
  openstack_networking_network_v2.kube_router
  openstack_compute_instance_v2.kubernetes_worker
  openstack_networking_subnet_v2.internal
  openstack_networking_subnet_v2.kube_router
  data.openstack_networking_network_v2.external_network
  openstack_compute_instance_v2.kubernetes_etcd
  openstack_networking_router_interface_v2.internal
  openstack_networking_router_v2.internal
  openstack_compute_instance_v2.kubernetes_master
  openstack_networking_network_v2.internal

Do you want to make these changes?
Only 'yes' will be accepted to continue.

Enter a value: yes

Successfully replaced provider for 11 resources.
1
votes

While you were under TF13 did you apply state at least once for the running project?

According to TF docs: https://www.terraform.io/upgrade-guides/0-14.html

There is no automatic update command (separately) in 0.14 (like there was in 0.13). The only way to upgrade is to force state on a project at least once, while under command when moving TF13 to 14.

You can also try terraform init in the project directory.

0
votes

We encountered a similar problem in our operational environments today. We successfully completed the terraform 0.13upgrade command. This indeed introduced a versions.tf file.

However, performing a terraform init with this setup was still not possible, and the following error popped up:

Error: Invalid legacy provider address

Further investigation in the state file revealed that, for some resources, the provider block was not updated. We hence had to run the following command to finalize the upgrade process.

terraform state replace-provider "registry.terraform.io/-/google" "hashicorp/google"

EDIT Deployment to the next environment revealed that this was caused by conditional resources. To easily enable/disable some resources we leverage the count attribute and use either 0 or 1. For the resources with count = 0, that were unaltered with Terraform 0.13, the provider was not updated.