Terraform-provider-google: Version 2.20.0 breaking google_bigquery_table expected specifier?

Created on 15 Nov 2019  ·  10Comments  ·  Source: hashicorp/terraform-provider-google


Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment
  • If an issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to "hashibot", a community member has claimed the issue already.

Terraform Version

Terraform v0.12.13

Affected Resource(s)

  • google_bigquery_table

Terraform Configuration Files

resource "google_bigquery_table" "activities_table" {
  dataset_id = "${google_bigquery_dataset.activities_dataset.dataset_id}"
  table_id   = "activities"

  schema = <<EOF
[
  {
    "description": "id",
    "name": "id",
    "type": "INTEGER",
    "mode": "NULLABLE"
  }
]
EOF
}

Debug Output

Output from plan command:

Invalid BigQuery table specifier. Expecting projects/{{project}}/datasets/{{dataset}}/tables/{{table}}, got project-staging:activities.activities

Panic Output

Expected Behavior

In this case, I am changing unrelated features and the tables haven't changed on the infrastruture. I would expect for it to continue with the plan and not error on reading the bigquery table state.

Actual Behavior

The plan process fails with the above output.

Steps to Reproduce

  1. Have an existing terraform state with a bigquery table resource
  2. Run terraform plan

Important Factoids

If version 2.19.0 is specified, it does not error. Perhaps related to 2.20.0 release?

This plan command is failing on a state file with existing table resources. The changes in the new plan are unrelated.

References

bug

Most helpful comment

I'd recommend using version restraints to pin to a specific release / release series as shown in https://www.terraform.io/docs/providers/google/guides/version_3_upgrade.html#provider-version-configuration.

I believe this would lock you to the 2.X series:

provider "google" {
  # ... other configuration ...

  version = "~> 2.0"
}

It may not be possible to revert, since going from 2.X -> 3.X could have modified statefiles in incompatible ways. Regardless, this paragraph contains instructions on how. For what it's worth, 3.0.0-beta.1 is a fairly complete version of 3.0.0.

All 10 comments

Seems like https://github.com/terraform-providers/terraform-provider-google/pull/4680/files#diff-cbec323b17374a909a0b4b360c9d3a8aR480 may be the related change here.

Can you confirm your provider version is 2.20.0 and not 3.0.0-beta.1?

I am getting this error now as well without having changed any configuration at all (all I did was change source code that some Cloud Functions are using and the BigQuery resources aren’t a part of that). Where is the above code being referenced/called in Terraform Plan?

@KimRomBot can you also confirm your version?

@rileykarson

Terraform v0.12.16
provider.archive v1.3.0
provider.google v3.0.0-beta.1

So it is indeed 3.0.0-beta.1! Is there any way to tell Terraform to use the latest stable version?

I'd recommend using version restraints to pin to a specific release / release series as shown in https://www.terraform.io/docs/providers/google/guides/version_3_upgrade.html#provider-version-configuration.

I believe this would lock you to the 2.X series:

provider "google" {
  # ... other configuration ...

  version = "~> 2.0"
}

It may not be possible to revert, since going from 2.X -> 3.X could have modified statefiles in incompatible ways. Regardless, this paragraph contains instructions on how. For what it's worth, 3.0.0-beta.1 is a fairly complete version of 3.0.0.

I had the same issue and can confirm that pinning the provider's version to 2.X (e.g. 2.16.0) solves the problem.

The new version v3.0.0-beta.1 seems to have a bug.

Thanks for confirming the version! It looks like we didn't catch that this resource relies directly on the id value, which isn't true of most resources anymore. Changing the format ended up being incompatible, but not in a way that our tests caught.

I'm working on a fix, I'll try to get it in for the 3.0.0 release ~Tuesday. If it misses that, it should land in 3.1.0 ~Thursday next.

This should work again in 3.1.0, I missed the cutoff for 3.0.0 by a day. Sorry for the breakage! 3.1.0 should be later this week.

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

Was this page helpful?
0 / 5 - 0 ratings