Fix bigtable_gc_policy: the read was not using the right column name

[jcanseco]

If this PR is for Terraform, I acknowledge that I have:

• [x] Searched through the issue tracker for an open issue that this either resolves or contributes to, commented on it to claim it, and written "fixes {url}" or "part of {url}" in this PR description. If there were no relevant open issues, I opened one and commented that I would like to work on it (not necessary for very small changes).
• [x] Generated Terraform, and ran make test and make lint to ensure it passes unit and linter tests.
• [ ] Ensured that all new fields I added that can be set by a user appear in at least one example (for generated resources) or third_party test (for handwritten resources or update tests).
• [ ] Ran relevant acceptance tests (If the acceptance tests do not yet pass or you are unable to run them, please let your reviewer know).
• [x] Read the Release Notes Guide before writing my release note below.

Release Note Template for Downstream PRs (will be copied)

bigtable: Fixed broken read logic in `google_bigtable_gc_policy`

[modular-magician]

Hello! I am a robot who works on Magic Modules PRs.

I have detected that you are a community contributor, so your PR will be assigned to someone with a commit-bit on this repo for initial review.

Thanks for your contribution! A human will be with you soon.

@slevenick, please review this PR or find an appropriate assignee.

[modular-magician]

Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are.

Diff report:

Terraform GA: Diff ( 1 file changed, 6 insertions(+), 4 deletions(-)) Terraform Beta: Diff ( 1 file changed, 6 insertions(+), 4 deletions(-))

[modular-magician]

I have triggered VCR tests based on this PR's diffs. See the results here: "https://ci-oss.hashicorp.engineering/viewQueued.html?itemId=159683"

[modular-magician]

I have triggered VCR tests in RECORDING mode for the following tests that failed during VCR: TestAccDataSourceSpannerInstance_basic|TestAccActiveDirectoryDomainTrust_activeDirectoryDomainTrustBasicExample|TestAccBigqueryDataTransferConfig|TestAccComposerEnvironment_withUpdateOnCreate|TestAccComputeTargetInstance_targetInstanceCustomNetworkExample|TestAccFilestoreInstance_filestoreInstanceBasicExample|TestAccFilestoreInstance_update|TestAccProjectIamCustomRole_basic|TestAccOSLoginSSHPublicKey_osLoginSshKeyExpiry|TestAccSpannerDatabase_basic|TestAccStorageBucket_cors You can view the result here: "https://ci-oss.hashicorp.engineering/viewQueued.html?itemId=159687"

[slevenick]

So if I'm reading this right the existing logic will only successfully read the gc policy if the family name is the same as the gc policy name?

[jcanseco]

So if I'm reading this right the existing logic will only successfully read the gc policy if the family name is the same as the gc policy name?

The existing logic will only successfully read the GC policy if the GC policy's column name happens to match the table name.

[rileykarson]

As I understand it will fail to (re-)set the id, so even with the error the resource still generally worked. Or am I misunderstanding it?

This would probably affect the import if the resource supported it.

[jcanseco]

Yep, my understanding is the same. There shouldn't have been issues for Terraform in particular I think. This was just an issue for us since we're reliant on the TF Read correctly setting the ID if the resource exists.

[kevinsi4508]

This will fail to detect if a gc policy is updated outside of TF. Can we get this reviewed and committed? Thanks!