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

Endpoints service incorrectly generates config_id #10164

Closed
adambabik opened this issue Sep 25, 2021 · 5 comments
Closed

Endpoints service incorrectly generates config_id #10164

adambabik opened this issue Sep 25, 2021 · 5 comments
Assignees
Labels

Comments

@adambabik
Copy link

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 v1.0.7
on darwin_amd64

  • provider registry.terraform.io/hashicorp/google v3.85.0
  • provider registry.terraform.io/hashicorp/template v2.2.0

Affected Resource(s)

  • google_endpoints_service

Terraform Configuration Files

I am providing only relevant fragment:

data "template_file" "api_config" {
  template = file("api_config.yaml.tpl")
  vars = {
    name = "${google_cloud_run_service.gateway.name}.endpoints.${var.project_id}.cloud.goog"
    api_service_address = trimprefix(google_cloud_run_service.api.status.0.url, "https://")
  }
}

resource "google_endpoints_service" "api" {
  service_name         = "${google_cloud_run_service.gateway.name}.endpoints.${var.project_id}.cloud.goog"
  project              = var.project_id
  grpc_config          = data.template_file.api_config.rendered
  protoc_output_base64 = filebase64("api.pb")
}

Expected Behavior

When running terraform apply, it renders the following plan related to the problematic endpoints service:

# google_endpoints_service.api will be updated in-place
  ~ resource "google_endpoints_service" "api" {
      ~ config_id            = "2021-09-24r3" -> "2021-09-25r0"
      ~ grpc_config          = redacted
        id                   = "docci-gateway.endpoints.docci-test-1.cloud.goog"
        # (6 unchanged attributes hidden)
}

It's important to notice that the dependency of google_endpoints_service, i.e. template_file.api_config detects a change too because google_cloud_run_service.gateway changes, however, the rendered content itself does not change.

The config_id in this case should not change because there are no changes that would result in a new revision.

The apply command should succeed.

Actual Behavior

The apply command fails because the Endpoints Service returns the old config_id while the provider thinks it should be updated:

╷
│ Error: Provider produced inconsistent final plan
│
│ When expanding the plan for google_endpoints_service.api to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/google" produced an invalid new value for .config_id:
│ was cty.StringVal("2021-09-25r0"), but now cty.StringVal("2021-09-24r3").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵

Steps to Reproduce

  1. terraform apply

Important Factoids

I believe this might be related to grpc_config = data.template_file.api_config.rendered and the fact that the provider cannot determine whether the content of it will result in a new config_id or not. On the other hand, the content does not change at all but it seems not to be verified by the provider.

It's important to notice that a consecutive call of terraform apply will succeed and bring back the config_id value to the previous one.

@adambabik adambabik added the bug label Sep 25, 2021
@melinath melinath self-assigned this Sep 30, 2021
@melinath
Copy link
Collaborator

melinath commented Oct 1, 2021

It looks like config_id is a Computed field, which means that users are not able to update it directly. However, we do use a CustomizeDiff func to automatically provide a "preview" of what we expect the value to be post-apply (if we're able to guess.) In this case, because TF detected a change, the provider generated a new config_id - but the server didn't update the config_id because there wasn't actually a change.

The fix for this should be a diff suppress func to ignore changes to the grpc_config field if the content is identical.

@adambabik is the rendered content literally exactly the same or does it have meaningless formatting changes?

@adambabik
Copy link
Author

@melinath in my case the rendered content is exactly the same. What changes are the resources the rendered content depends on but not really the actual values used by it. For example, google_cloud_run_service.gateway does change as a whole but not google_cloud_run_service.gateway.name.

@melinath
Copy link
Collaborator

melinath commented Oct 5, 2021

@adambabik I'm able to reproduce this bug in Terraform 1.0+. It looks like template_file is only recommended for tf <0.11. In my testing, using templatefile resolves the issue in 1.0.X. Does that work for you as well?

@adambabik
Copy link
Author

@melinath I run only a very simple check but it works as expected now with templatefile(), that is it does not detect unnecessary changes. I hope I will have a bit more time this week to battle test this. I think we can close this issue and I will reopen it if it happens again. Thanks!

@github-actions
Copy link

github-actions bot commented Nov 7, 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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 7, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants