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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using default_labels on Google Terraform provider forces replacement of google_datastream_private_connection #17670

Closed
darraghcopley opened this issue Mar 25, 2024 · 5 comments

Comments

@darraghcopley
Copy link

darraghcopley commented Mar 25, 2024

Using default_labels on Google Terraform provider (5.21.0) forces replacement of google_datastream_private_connection

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

1.7.4

Affected Resource(s)

google_datastream_private_connection

Terraform Configuration

resource "google_datastream_private_connection" "read_replicas_private_connection" {
  display_name          = "Datastream ${var.gcp_project_id} with SVPC"
  location              = var.region
  private_connection_id = "datastream-peering-${var.gcp_project_id}-svpc"

  vpc_peering_config {
    vpc    = var.datastream_vpc
    subnet = var.datastream_peering_subnet
  }
}
provider "google" {
  region         = var.region
  project        = var.gcp_project_id
  default_labels = {
    test_label = "test_val_to_force_replacement"
  }
}
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.21.0"
    }
  }
}

Debug Output

No response

Expected Behavior

The resource should be updated in place and not need to be recreated in order to add labels to it

Actual Behavior

Screenshot 2024-03-25 at 16 00 36

As seen in the plan, the labels, as expected, are to be applied on every resource created via the provider. However, on the resource google_datastream_private_connection it forces a replacement due to the effective_labels attribute

Steps to reproduce

  1. terraform plan

Important Factoids

No response

References

No response

b/331218290

@github-actions github-actions bot added forward/review In review; remove label to forward service/datastream labels Mar 25, 2024
@ggtisc ggtisc self-assigned this Mar 25, 2024
@ggtisc
Copy link
Collaborator

ggtisc commented Mar 25, 2024

Confirmed issue after replication! This may be an enhancement because there is no error message but as it seems when the default_labels were added it attempts to destroy the existing resources and replace with new ones instead of only update the existing resources.

@ggtisc ggtisc added enhancement and removed bug forward/review In review; remove label to forward labels Mar 25, 2024
@darraghcopley
Copy link
Author

Thanks for the quick reply @ggtisc ! Understood rgd enhancement over bug. I do think this is not expected behaviour however. Destroying and recreating the resource would cause quite some issues for other Datastream resources depending on it

@rileykarson
Copy link
Collaborator

@zli82016 to triage

@zli82016
Copy link
Collaborator

zli82016 commented Apr 29, 2024

As the resource google_datastream_private_connection API doesn't support in-place update, the resource has to be recreated to add default labels on the field effective_labels.

@zli82016
Copy link
Collaborator

zli82016 commented May 3, 2024

The behavior is expected. Feel free to reopen it if there are any questions.

@zli82016 zli82016 closed this as completed May 3, 2024
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

5 participants