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

google_folder recreates folder when tags field is changed #19602

Open
imrannayer opened this issue Sep 24, 2024 · 4 comments
Open

google_folder recreates folder when tags field is changed #19602

imrannayer opened this issue Sep 24, 2024 · 4 comments

Comments

@imrannayer
Copy link

imrannayer commented Sep 24, 2024

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 a user, that user is claiming responsibility for the issue.
  • Customers working with a Google Technical Account Manager or Customer Engineer can ask them to reach out internally to expedite investigation and resolution of this issue.

Terraform Version & Provider Version(s)

Terraform v1.6.5
on linux_amd64

  • provider registry.terraform.io/hashicorp/google v6.4.0
  • provider registry.terraform.io/hashicorp/google-beta v6.4.0

Affected Resource(s)

google_folder

Terraform Configuration

resource "google_folder" "department1" {
  display_name = var.name
  parent       = var.parent
  tags         = {
    "${data.google_tags_tag_key.environment_tag_key.id}" = data.google_tags_tag_value.environment_prod_tag_value.id
  }
  deletion_protection = false
}

Debug Output

No response

Expected Behavior

When tags field should be updatable without recreating the folder.

Actual Behavior

  # google_folder.department1 must be replaced
-/+ resource "google_folder" "department1" {
      ~ create_time         = "2024-09-24T15:52:01.074Z" -> (known after apply)
      ~ folder_id           = "22874620744" -> (known after apply)
      ~ id                  = "folders/22874620744" -> (known after apply)
      ~ lifecycle_state     = "ACTIVE" -> (known after apply)
      ~ name                = "folders/22874620744" -> (known after apply)
      - tags                = { # forces replacement
          - "tagKeys/281482284615220" = "tagValues/281481045753841"
        } -> null
        # (3 unchanged attributes hidden)
    }

Steps to reproduce

  1. terraform apply
  2. change tags field
  3. terraform apply

Important Factoids

No response

References

No response

b/370524999

@imrannayer imrannayer added the bug label Sep 24, 2024
@github-actions github-actions bot added forward/review In review; remove label to forward service/cloudresourcemanager-crm labels Sep 24, 2024
@ggtisc ggtisc self-assigned this Sep 27, 2024
@ggtisc
Copy link
Collaborator

ggtisc commented Sep 27, 2024

Hi @imrannayer!

This is considered a normal behavior since according to terraform registry this field is immutable and causes resource replacement when mutated.

@imrannayer
Copy link
Author

@ggtisc this will make the feature unusable. I am using google_tags_tag_binding to attach bindings instead of directly passing tags values in google_folder to avoid this problem.

@ggtisc
Copy link
Collaborator

ggtisc commented Sep 30, 2024

I'm forwarding this to check if it is possible an enhancement in future releases

@ggtisc ggtisc removed their assignment Sep 30, 2024
@ggtisc ggtisc added enhancement and removed bug forward/review In review; remove label to forward labels Sep 30, 2024
@melinath
Copy link
Collaborator

Note from triage: This is a request for update support on the API side, so I'm marking it as a feature request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants