Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deprecation warning for bigtable gc policies creates impossible situation #8539

Closed
wyardley opened this issue Feb 23, 2021 · 2 comments
Closed
Assignees
Labels

Comments

@wyardley
Copy link

wyardley commented Feb 23, 2021

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.

Hello
We started getting deprecation warnings like this:

for bt gc policies, we got the following error:
Warning: Deprecated Attribute
  on bigtable.tf line 34, in resource "google_bigtable_gc_policy" "foo":
  34:     days = 3
Deprecated in favor of duration
(and 19 more similar warnings elsewhere)

That's fine, so Ok, we change 3d to, say, 72h. At that point, though, terraform apply returns the error
Error: doesn't support update if we try to a change like this

  ~ resource "google_bigtable_gc_policy" "foo" {
        id            = "(age() > 3d || versions() > 1)"
        # (5 unchanged attributes hidden)

      ~ max_age {
          - days     = 3 -> null
          + duration = "72h"
        }

        # (1 unchanged block hidden)
    }

We can remove the state and try to reimport it, however, then we find out that this is not an importable resource

Error: resource google_bigtable_gc_policy doesn't support import

It may be safe to simply remove the state, reapply everything, and not worry about dupe resources being left behind, but I don't know enough about bt garbage-collection policies to know if this is safe / sane. In either event, the current experience is frustrating.

Terraform Version

Terraform v0.14.7
+ provider registry.terraform.io/hashicorp/google v3.56.0
+ provider registry.terraform.io/hashicorp/google-beta v3.56.0

(tried with 3.57.0 as welll)

Affected Resource(s)

  • google_bigtable_gc_policy

Terraform Configuration Files

resource "google_bigtable_gc_policy" "foo" {
  instance_name = module....
  table         = module....
  column_family = "data"

  max_age {
    duration = "72h"
  }
}

Debug Output

can provide if needed

Panic Output

Expected Behavior

When changing from, say, 30d to 720h for duration, we'd expect that the change will be a noop or state only change

Actual Behavior

Terraform gives the error

Error: doesn't support update

Steps to Reproduce

  1. terraform apply

Important Factoids

References

@ghost ghost added bug labels Feb 23, 2021
@venkykuberan venkykuberan self-assigned this Feb 24, 2021
@rileykarson
Copy link
Collaborator

Deduping to #8416

@ghost
Copy link

ghost commented Mar 27, 2021

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 👉 hashibot-feedback@hashicorp.com. Thanks!

@ghost ghost locked as resolved and limited conversation to collaborators Mar 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants