Provider version conflict

itzzmeshashi · January 19, 2020, 7:44pm

Hi,

I’ve recently upgrade to v0.12.19 of terraform and I’m getting the below error when performing a plan:

Error: Resource instance managed by newer provider version
The current state of google_compute_address.gcp-test was created by a
newer provider version than is currently selected. Upgrade the
Terraform Registry provider to work with this state.

And my current version’s are:

terraform version
Terraform v0.12.19

provider.google v3.4.0

v3.4 is the latest for google provider, I’m unable to understand the error.
Can someone please help

Thanks!!

apparentlymart · January 22, 2020, 5:43pm

Hi @itzzmeshashi,

The internal mechanism that leads to this error is that the provider specifies a “schema version” number for each resource type, which Terraform then records in the state so that the provider can know when it needs to run a schema upgrade on a future run. This error appears in the unusual situation where the schema version in the state is newer than the latest version the provider knows about.

However, this particular case is weird because as far as I can tell (from looking at the GCP provider code) there has not been any increase in the schema version number for the google_compute_address resource type. (There’s no schema version specified explicitly at all, which implies it’s still on schema version zero.)

It seems that something unusual is recorded in your latest state snapshot. Could you run terraform state pull to retrieve your state and then look in there for the google_compute_address.gcp-test resource state? Nested somewhere under that JSON object you should see a schema_version value, which based on the GCP provider code I linked above I’d expect to have the value 0. Is the value in your state non-zero?

itzzmeshashi · January 23, 2020, 5:30am

Hi Martin@apparentlymart,

Thanks for the help on this!!
With latest terraform and provider versions i did a “state pull” and for the the “google_compute_address” resource the schema version was “1”. Except for that all the others resources were on “0” version as you mentioned.

I did a “terraform state rm” of that resource and again added to state using “terraform import” then it changed backed to schema version of “0”. Now I can do an plan for my changes.

What I want to know is:

Why was this caused in the first place, so that we don’t repeat the mistake?
The fix what I did, is it the correct way to handle this kind of errors?

Thanks

apparentlymart · January 23, 2020, 6:18pm

Hi @itzzmeshashi,

Unfortunately I don’t know how that situation could’ve occurred.

I’ve not heard of this issue showing up before except in situations where the provider schema has changed and where the resolution is therefore to just use the correct provider version.

Your situation is very strange because as far as I can tell there has never been a version 1 of google_compute_address schema and so I don’t know why the state would be updated that way. On the plus side, I’ve never seen this problem before now so hopefully it was a one-off anomaly for some specific unlikely sequence of events and thus it’s unlikely to happen again. I know that’s not a satisfying answer.

Your workaround of making Terraform forget and then re-import the resource is a find workaround here: that caused the GCP provider to recreate the state based on the upstream resource and the current schema version 0. If you do see this problem appear again, and you’re able to delay the fix to enable some further debugging, it could be helpful to file an issue about it in the GCP provider repository; the maintainers of the provider may have additional context about changes to provider schema etc that I’m not aware of, and so they might be able help identify a specific cause.

matthewsanders · March 27, 2020, 12:11am

I appear to be getting a similar issue with the AWS provider.

The current state of aws_db_instance.my_db was created by a
newer provider version than is currently selected. Upgrade the
registry.terraform.io/-/aws provider to work with this state.

When I pull the state from S3 I notice that most of the resources have a schema of 0 but I have two with a schema of 1: aws_db_instance and aws_dynamodb_table

I’m assuming this is the resource:

github.com

terraform-providers/terraform-provider-aws/blob/master/aws/resource_aws_db_instance.go

package aws

import (
	"fmt"
	"log"
	"regexp"
	"strconv"
	"strings"
	"time"

	"github.com/aws/aws-sdk-go/aws"
	"github.com/aws/aws-sdk-go/service/rds"
	"github.com/hashicorp/terraform-plugin-sdk/helper/resource"
	"github.com/hashicorp/terraform-plugin-sdk/helper/schema"
	"github.com/hashicorp/terraform-plugin-sdk/helper/validation"
	"github.com/terraform-providers/terraform-provider-aws/aws/internal/keyvaluetags"
)

func resourceAwsDbInstance() *schema.Resource {
	return &schema.Resource{

This file has been truncated. show original

currently it appears to have: SchemaVersion: 1

Is there a way to determine the version of the provider thinks it is using? How do I resolve this without destroying the DB?

itzzmeshashi · March 27, 2020, 5:15am

Hi Matthew,

I only solution available ( as i searched google) was to do rm of the resource and import it again to terraform, which changes that version.

Also this does not delete the actual resource “destroy” does that, and you can use “terraform state list” to view the version every resource is using.

Hope this helps!!

matthewsanders · March 27, 2020, 5:31am

Thanks itzzmeshashi,

That is what I eventually did and it resolved the issue. I didn’t change my configuration and did a terraform rm on my specific resource and followed by a terraform import as you mentioned.

mehaksatija · June 25, 2020, 6:20am

I faced the same issue in a local plan, resolved it by removing folder .terraform and then doing init and plan again.

navneethece · May 18, 2021, 1:11pm

How will this work for Terraform Cloud ? How can we remove the state of a Terraform Cloud if we are presented with the same error for azurerm provider?
Do not see any steps to remove the state file for Terraform cloud.