Support undelete in google_endpoints_service resource

djbingham commented 1 year ago

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 the 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 the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

I would like to be able to destroy and re-apply Terraform containing a google_endpoints_service resource without changing its service name. This is currently impossible because a deleted endpoint is held for 30 days and blocks the creation of a new resource with the same name.

Example Terraform from the provider documentation, which fails to reapply after a destroy run:

resource "google_endpoints_service" "openapi_service" {
  service_name   = "api-name.endpoints.project-id.cloud.goog"
  project        = "project-id"
  openapi_config = file("openapi_spec.yml")
}

A solution to this is provided by the ensure_undelete option in the endpoints-dns module, which uses an external data source to undelete using the gcloud CLI tool. However, as I am running in Terraform Cloud, I do not have gcloud available. It is possible to use the gcloud module to download the CLI tool on each run, but that has proven very inefficient and unreliable for me.

Given that undelete is supported by the API and the gcloud CLI, please could an option be considered to support undelete directly in the endpoints service resource?

New or Affected Resource(s)

google_endpoints_service

Potential Terraform Configuration

resource "google_endpoints_service" "foo_service" {
  service_name   = "api-name.endpoints.project-id.cloud.goog"
  project        = "project-id"
  openapi_config = file("openapi_spec.yml")

  allow_create_by_undelete = true
}

References

Endpoints DNS Terraform module: https://github.com/terraform-google-modules/terraform-google-endpoints-dns
gcloud Terraform module: https://github.com/terraform-google-modules/terraform-google-gcloud
API endpoint (I think) to undelete an endpoints service: https://github.com/googleapis/googleapis/blob/96995a259201719658dbaad83a7cb907b28dab26/google/api/servicemanagement/v1/servicemanager.proto#L117

This was previously requested in 2021 and in a comment on a similar request for the google_project resource in 2019. There seemed to be some support for this in 2019, but nobody picked up the work. There was a terse response to the 2021 request which amounted to "undelete is hard, so we're not interested". I'm puzzled by that response, given that undelete is supported by the API, the gcloud CLI tool and (via a clunky workaround) the Terraform module.

2019 request: https://github.com/hashicorp/terraform-provider-google/issues/1101#issuecomment-465158024
2021 request: https://github.com/hashicorp/terraform-provider-google/issues/8752

b/302673036

rileykarson commented 8 months ago

There was a terse response to the 2021 request which amounted to "undelete is hard, so we're not interested". I'm puzzled by that response, given that undelete is supported by the API, the gcloud CLI tool and (via a clunky workaround) the Terraform module.

I can provide context on that- there has been an ebb and flow of opinions and pressures on the provider team wrt. what level of deviation from APIs we should have, how we want to maintain non-standard resources, etc. Around that time we were at the high end of "Terraform should only work with standard resources/actions" due to a mix of factors. We should have moved the issue to the Backlog milestone though, rather than closing it, since that'd still allow folks to weigh in.

This seems reasonable to me- there's an argument either way whether the imperative undelete action should be represented in Terraform or not- it's a little weird to call undelete when Terraform just thinks it's creating something as it's not entirely in the plan, but it enables interaction through CI systems with just terraform apply. We lean more towards adding flows like that than not now. That'd also be reasonable to consider for project too.

djbingham commented 8 months ago

Thank you for the explanation @rileykarson, that makes complete sense. I'm glad you lean more towards adding this sort of flow now. It's been a while but this is still a feature I would very much appreciate.

hashicorp / terraform-provider-google