terraform-provider-google: Self-referential error enabling the Service Usage API
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-magicianuser, 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 tohashibot, a community member has claimed the issue already.
Terraform Version
Terraform v1.0.1
on darwin_amd64
+ provider registry.terraform.io/hashicorp/google v3.66.1
+ provider registry.terraform.io/hashicorp/random v3.1.0
+ provider registry.terraform.io/hashicorp/tfe v0.25.2
Affected Resource(s)
- google_project_service
Terraform Configuration Files
resource "google_project_service" "prerequisites" {
for_each = toset([
"serviceusage.googleapis.com",
"cloudresourcemanager.googleapis.com",
])
project = google_project.my_project.project_id
service = each.value
disable_on_destroy = false
disable_dependent_services = false
}
Debug Output
https://gist.github.com/PatrickDale/321a68360b28632d19a89144199058f3
Expected Behavior
Running terraform apply should have enabled the Service Usage API (serviceusage.googleapis.com).
Actual Behavior
terraform apply failed with the error:
Error waiting for Enable Project "<project-id>" Services: [serviceusage.googleapis.com]: error while retrieving operation: googleapi: Error 403: Service Usage API has not been used in project <project-number> before or it is disabled.
Steps to Reproduce
terraform apply
Important Factoids
This operation was ran in Terraform Cloud using a service account that has permissions to enable services on this GCP project.
It seems like this error is self-referential – it states that it cannot enable serviceusage.googleapis.com because the Service Usage API is disabled. From the terraform logs, it looks like the error comes from:
https://github.com/hashicorp/terraform-provider-google/blob/512259e45a3f0b3f54832f788d36e8227c343fe0/google/resource_google_project.go#L631-L634
After receiving the error, I checked the GCP console and the Service Usage API was enabled. I then ran terraform apply again which passed.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 3
- Comments: 36 (1 by maintainers)
Note that releases are paused until 4.0 version of the provider which should release some time next week.
We pushed a change just now that should release next Monday. Please let us know if you continue to experience this issue after this change hits. We were unable to reproduce the issue listed due to it’s transient nature but are confident in our fix.
Hi @c4po, I’ve been pulled in many different directions as of late so this particular issue snuck away from me. I’ve set aside some time to play with it to hopefully address this during the week.
The permission fix I’ve checked in might already resolve this issue in your scenario but I still want to see if I can get the retrial going.
I think the quota project will be
project-bregardless of version. The project service resource doesn’t know to check for a billing project, but does know to use the resource project whenuser_project_overrideis set. So even in later versions wherebilling_projectis applied at the provider level, the resource project will override it because there’s no way to trigger only the provider-levelbilling_projectfield. (And we should probably fix that so it knows to check for a billing project)@ScottSuarez: I may have pointed you on a bit of a wild goose chase given that- sorry about that! We’re almost certainly dealing with operations needing the service enabled, but enabling the service not needing it- and we’ll likely want to retry 403s on the operation here.
Hey @leighmhart, it looks like this is still happening; we’ve just ran into the issue again today:
Unfortunately we’ve noticed that this doesn’t happen consistently, so it’s hard to reproduce.