Predict service_id in endpoints_service fixed to timezone "America/Los_Angeles"

[alx-andru]

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.4
on darwin_amd64

Affected Resource(s)

• google_endpoints_service

Terraform Configuration Files

resource "google_endpoints_service" "openapi_service" {
  service_name = "my-service-name"
  project      = "my-gcp-projectId"
  openapi_config = sensitive(templatefile("./swagger.json", {
    host = "my-service-name"
  }))
}

Debug Output

Panic Output

https://gist.github.com/alx-andru/17ef1dc59f62e0c76385c90b34d56fd9

Expected Behavior

I would expected that the config_id is matching the current date and be based on version increments.

Actual Behavior

The "predicted" config_id is based on a hard-coded timezone that, when run close to midnight, causes the prediction to be offset by a day, depending on the timezone of your local system.

Steps to Reproduce

1. terraform apply

Important Factoids

• Running in timezone "Americas/Toronto" before shortly before midnight
• Set the Execution Mode to Local

References

I opened a PR with a suggested change but realized that the issue is also in the general google provider as well.

• Predict serviceId based on service runner location terraform-provider-google-beta#3493
• https://github.com/hashicorp/terraform-provider-google/blob/master/google/resource_endpoints_service.go#L158

[edwardmedia]

@alx-andru can you provide a swagger.json and the debug log (how)?

Thank you for the contribution. Here is the repo that generates the providers.

[alx-andru]

Hi @edwardmedia , the swagger.json is fairly simple and deployments in general work. You can see the schema I used to test here https://gist.github.com/alx-andru/88947d8944d016722635404dbd9b7f1e

I'll try to reproduce it in debug mode tonight, setting my local time didn't result in the desired output I shared above.

[edwardmedia]

@alx-andru waiting for your debug log

[alx-andru]

Hey @edwardmedia I was able to reproduce it tonight and have piped the output into a log file which is here:

https://gist.github.com/alx-andru/13efcfab732cc799de7f47e0e8ac6863

My timezone is Americas/Toronto and I was running this shortly before midnight.

I'd expect to see the predicted configId to be 2021-08-11r1 and not 2021-08-10r0

"config_id" = "2021-08-11r0" -> "2021-08-10r0"

[edwardmedia]

@alx-andru I see what you refer to. But config_id is readonly and autogenerated. As a reference, help me to understand why the value of date matters? I saw your suggestion below. Does it compile?

loc, err := time.LoadLocation("America/Los_Angeles") --->	loc, err := time.Location()

[alx-andru]

@edwardmedia when terraform apply runs, the validation at the end to determine a successful run is failing because the predicted config_id is not matching the deployed config_id.

The suggestion is really just a suggestion as I'm not a go developer and don't know how to compile/run the project. I did some reading in the documentation on what LoadLocation returns and how it should work and found the reference to time.Location().

[edwardmedia]

@alx-andru Trying to understand why it is failing. could you get the debug log (how)? You may set below environment variable before run tf apply

export TF_LOG=DEBUG

[alx-andru]

@edwardmedia please see following output that I reproduced by changing my date settings locally which results in the exact same output I had when running tests closer to midnight.
https://gist.github.com/alx-andru/973e4d1e0e9dfc79bedf82f5ec5c7b5b#file-terraform-log-L798

The key part is that the preview shows

-/+ resource "null_resource" "esp" {
      ~ id       = "8572916787066051597" -> (known after apply)
      ~ triggers = { # forces replacement
          ~ "config_id" = "2021-08-22r0" -> "2021-08-21r0"
          ~ "sha"       = "82d098a" -> "b4d878c"
        }
    }

but the actual deployment is using the correct config_id (2021-08-22r1) generated by gcp

produced an invalid new value for .triggers["config_id"]: was cty.StringVal("2021-08-21r0"), but now cty.StringVal("2021-08-22r1").

[edwardmedia]

@alx-andru Sorry I don't get it. Is below hint what you referred to failing? Why it matters? Most of time you could ignore it. Do you need to bring the resource update to date based on this field?

config_id: was cty.StringVal("2021-08-21r0"), but now cty.StringVal("2021-08-22r1")

[alx-andru]

@edwardmedia everything seems to get fully deployed but the actual "apply" fails. So if it runs through CI/CD it would just be marked as "failed" rather than a success.

[github-actions]

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.