terraform-provider-google
terraform-provider-google copied to clipboard
"name" field on google_apikeys_key leads to errors when re-creating issues.
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
The name
field of the google_apikeys_key
resource is exposed, and even mandatory.
It seems to be used as a per project unique identifier, however, on resource deletion, previously used values for this field are not immediately made available again (it's been about a day in my case, I have no idea at this point if previous names are eventually released)
This causes an error when creating an api key, deleting it, and attempting to re-create it with the same configuration :
Error: Error creating Key: Resource already exists - apply blocked by lifecycle params: &apikeys.Key{Name:(*string)(0xXXXX), DisplayName:(*string)(0xXXXX), KeyString:(*string)(0xXXXX), Restrictions:(*apikeys.KeyRestrictions)(0xXXXX), Project:(*string)(0xXXXX)}.
New or Affected Resource(s)
- google_apikeys_key
Potential Terraform Configuration
With the following minimal configuration :
resource "google_apikeys_key" "example" {
name = "example"
project = "your-project-id"
}
run :
$ terraform apply
# works
$ terraform destroy -target=google_apikeys_key.example
# works
$ terraform apply
# gives the error message above
Resolution suggestions
First of all, as a short term mitigation, this behavior should be explicited in documentation. #11725 addresses this.
Now, considering this field is not user-settable when creating a new API key from the GCP web interface, nor from the gcloud cli utility, I would suggest the following fixes :
- Make the
name
field optional. I have no idea if it is mandatory on the GCP API side, but if it is, generate a default value with the same format as other tools (looks like a UUIDv4 for keys created from the web interface) - Remove it from all documentation examples
- Ensure the documentation keeps being explicit regarding the risks of setting such a field
I assume this field is used in various places (say, logging...) and retaining the ability to set it presents value. Also, not removing it avoids a breaking change.
References
- #11725
b/374161786
Huh- according to https://cloud.google.com/api-keys/docs/reference/rest/v2/projects.locations.keys/create, The id must NOT be a UUID-like string.
(our name
field maps to the keyId
field there). However, the Console is definitely generating a UUIDv4.
Labelling as persistent-bug
, since this a bug that looks closer to an enhancement.
I just ran into this today. It is still an issue.
FYI I just ran into this today, and still an issue. Any updates on this? Thanks in advance!
In my case, I was able to work around this by using the "Restore deleted credentials" option in the GCP UI, and then doing terraform import
of the undeleted resource into the state. After that, Terraform was able to do an in-place update instead of recreating it.
I'm not sure if there is an API for this "Restore deleted credentials" feature, at least I couldn't find a gcloud
equivalent in the whole 5 seconds I looked for it.
Deleted credentials fully expire 30 days after deletion, and the ID remains taken for a while. One solution is to use a random suffix for the key ID, so it's different each time. Like this:
resource "random_id" "key_suffix" {
byte_length = 8
}
resource "google_apikeys_key" "api_key" {
name = "key-${random_id.key_suffix.hex}"
# ...
}