60

I'm trying to deploy a bitbucket pipeline using terraform v0.14.3 to create resources in google cloud. after running terraform command, the pipeline fails with this 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.

avivamg
  • 12,197
  • 3
  • 67
  • 61
Laura H.
  • 661
  • 1
  • 5
  • 6

11 Answers11

80

Solution

If you are using a newer version of Terraform, such as v0.14.x, you should:

  1. use the replace-provider subcommand

    terraform state replace-provider \
    -auto-approve \
    "registry.terraform.io/-/google" \
    "hashicorp/google"
    
    #=>
    
    Terraform will perform the following actions:
    
      ~ Updating provider:
        - registry.terraform.io/-/google
        + registry.terraform.io/hashicorp/google
    
    Changing x resources:
    
      . . .
    
    Successfully replaced provider for x resources.
    
  2. initialize Terraform again:

    terraform init
    
    #=>
    
    Initializing the backend...
    
    Initializing provider plugins...
    - Reusing previous version of hashicorp/google from the dependency lock file
    - Using previously-installed hashicorp/google vx.xx.x
    
    Terraform has been successfully initialized!
    
    You may now begin working with Terraform. Try . . .
    

    This should take care of installing the provider.

Explanation

Terraform only supports upgrades from one major feature upgrade at a time. Your older state file was, more than likely, created using a version earlier than v0.13.x.

If you did not run the apply command before you upgraded your Terraform version, you can expect this error: the upgrade from v0.13.x to v0.14.x was not complete.

You can find more information here.

Mike
  • 1,080
  • 1
  • 9
  • 25
Hassan Mussana
  • 1,274
  • 1
  • 9
  • 17
  • Hey @laura-h ! If this answer has solved your question, please consider accepting it by clicking the check-mark. This indicates to the wider community that you've found a solution and gives some reputation to both the answerer and yourself. – Hassan Mussana Feb 01 '21 at 12:25
39

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 :

  1. ensure syntax was upgraded by running terraform init again
  2. check the warnings and resolve them
  3. and finally updating the statefile with following method.
# update provider in state file
terraform state replace-provider -- -/aws hashicorp/aws

# reinit
terraform init

specific to 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.

mirageglobe
  • 2,446
  • 2
  • 24
  • 30
19

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.

kjmerf
  • 4,275
  • 3
  • 21
  • 29
4

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 
DeltaPng
  • 505
  • 4
  • 6
  • 1
    running terraform providers you can view which one is making the conflict. Thanks! – nrm97 Mar 09 '21 at 16:56
  • an explanation of what to look for in the output of `terraform providers` would be useful. – C.J. Jul 15 '21 at 22:18
3

Explanation: Your terraform project contains tf.state file that is outdated and refereeing to old provider address. The Error message will present this error:

Error: Invalid legacy provider address

This configuration or its associated state refers to the unqualified provider
<some-provider>.

You must complete the Terraform <some-version> upgrade process before upgrading to later
versions.

Solution: In order to solve this issue you should change the tf.state references to link to the newer required providers, update the tf.state file and initialize the project again. The steps are:

  1. Create / Edit the required providers block with the relevant package name and version, I'd rather doing it on versions.tf file.

example:

terraform {
  required_version = ">= 0.14"
  required_providers {
    aws = {
          source  = "hashicorp/aws"
          version = ">= 3.35.0"
        }
      }
    }
  1. Run terraform providers command to present the required providers from configuration against the required providers that saved on state.

example:

   Providers required by configuration:
.
├── provider[registry.terraform.io/hashicorp/aws] >= 3.35.0

Providers required by state:

    provider[registry.terraform.io/-/aws]
  1. Switch and reassign the required provider source address in the terraform state ( using terraform state replace-provider command) so we can tell terraform how to interpret the legacy provider.

The terraform state replace-provider subcommand allows re-assigning provider source addresses recorded in the Terraform state, and so we can use this command to tell Terraform how to reinterpret the "legacy" provider addresses as properly-namespaced providers that match with the provider source addresses in the configuration.

Warning: The terraform state replace-provider subcommand, like all of the terraform state subcommands, will create a new state snapshot and write it to the configured backend. After the command succeeds the latest state snapshot will use syntax that Terraform v0.12 cannot understand, so you should perform this step only when you are ready to permanently upgrade to Terraform v0.13.

example:

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

output:

  ~ Updating provider:
    - registry.terraform.io/-/aws
    + registry.terraform.io/hashicorp/aws
  1. run terraform init to update references.
avivamg
  • 12,197
  • 3
  • 67
  • 61
  • The `terraform state replace-provider registry.terraform.io/-/aws registry.terraform.io/hashicorp/aws` fixed it for me with aws provider - THNX – ActualAl Mar 31 '22 at 16:31
2

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.

Eric E
  • 199
  • 6
  • Thanks, this is a good point and I did not read the documentation closely enough initially to realize applying state was necessary. However I guess this would mean I would need to run it locally - which is not a good option in my circumstance... hoping there might be some way around this. – Laura H. Dec 22 '20 at 09:20
  • Try changing Hashicorp/Google (in req providers) to hashicorp/terraform-provider-google. I believe this is the new source link. Additionally, you should think of updating to google 3.5 (the latest versioning) – Eric E Dec 22 '20 at 20:22
2

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.
hbceylan
  • 968
  • 10
  • 10
1

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.

LaurensVijnck
  • 532
  • 6
  • 20
1

I recently ran into this using Terraform Cloud for the remote backend. We had some older AWS-related workspaces set to version 0.12.4 (in the cloud) that errored out with "Invalid legacy provider address" and refused to run with the latest Terraform client 1.1.8.

I am adding my answer because it is much simpler than the other answers. We did not do any of the following:

  terraform providers
  terraform 0.13upgrade  
  remove the .terraform folder
  terraform state replace-provider 

Instead we simply:

  1. In a clean folder (no local state, using local terraform.exe version 0.13.7) ran 'terraform init'
  2. Made a small insignificant change (to ensure apply would write state) to a .tf file in the workspace
  3. In Terraform Cloud set the workspace version to 0.13.7
  4. Using local 0.13.7 terraform.exe ran apply - that saved new state.
  5. Now we can use cloud and local terraform.exe version 1.1.8 and no more problems.

Note that we did also need to update a few AWS S3-related resources to the newer AWS provider syntax to get all our workspaces working with the latest provider.

Craig A
  • 1,368
  • 12
  • 11
0

I was using terragrunt with remote s3 state and dynamo db and sadly this does not work for me. So posting it here might help someone else.

A long way to make this work, as terragrunt state replace-provider does work for me

  • download the state file from s3
aws s3 cp s3://bucket-name/path/terraform.tfstate terraform.tfstate --profile profile
  • replace the provider using terraform
terraform state replace-provider "registry.terraform.io/-/random" "hashicorp/random"
terraform state replace-provider "registry.terraform.io/-/aws" "hashicorp/aws"
  • upload the state file back to s3 as even terragrunt state push terraform.tfstate does not work for me
aws s3 cp terraform.tfstate s3://bucket-name/path/terraform.tfstate --profile profile
  • terragrunt apply
  • the command will throw error with digest value,
  • update the dynamo db table digest value that received in previous command
Initializing the backend...
Error refreshing state: state data in S3 does not have the expected content.

This may be caused by unusually long delays in S3 processing a previous state
update.  Please wait for a minute or two and try again. If this problem
persists, and neither S3 nor DynamoDB are experiencing an outage, you may need
to manually verify the remote state and update the Digest value stored in the
DynamoDB table to the following value: fe2840edf8064d9225eea6c3ef2e5d1d

enter image description here

  • finally, run terragrunt apply enter image description here
Adiii
  • 54,482
  • 7
  • 145
  • 148
0

The other way that this can be strange is if you are using terraform workspaces - especially with the remote state files.

Using a terraform workspace - the order of operations is important.

  • terraform init - connecting to the default workspace
  • terraform workspace switch <env> - Even if you have specified the workspace here, the init will happen using the default workspace.

This is an assumption that terraform makes - sometimes erroneously

To fix this - you can run your init using:

TF_WORKSPACE=<your_env> terraform init

Or remove the default workspace.

Luke Exton
  • 3,506
  • 2
  • 19
  • 33