Terraform-provider-google: Wait and verify google_project_service is enabled before continuing

[sethvargo]

Terraform Version

Terraform v0.11.7
+ provider.google v1.10.0
+ provider.random v1.2.0
+ provider.tls v1.1.0

Affected Resource(s)

• google_project_service
• google_project_services

Terraform Configuration Files

resource "google_project" "demo" {
  name            = "my-project"
  project_id      = "my-project-abcd1234"
  org_id          = "..."
  billing_account = "..."
}

resource "google_project_service" "demo" {
  project = "${google_project.demo.project_id}"
  service = "cloudkms.googleapis.com"
}

# This will fail because Terraform will immediately try to create it after 
# "google_project_service.demo" returns success, but the upstream API
# is still provisioning.
resource "google_kms_key_ring" "demo" {
  name     = "demo"
  project  = "${google_project.demo.project_id}"
}

Expected Behavior

Terraform should not consider google_project_service(s) finished until the API is enabled AND ready.

Actual Behavior

Terraform assumes a successful response from the API means the API is finished.

Steps to Reproduce

1. terraform apply

Important Factoids

One could argue this is an API bug, we do long-poll to wait for SSH to be ready on an instance. I think we should do the same here.

/cc @danawillow @rosbo

[sethvargo]

In the meantime, I've done this, which brings me great sadness.

resource "google_project_service" "demo" {
  project = "${google_project.demo.project_id}"
  service = "cloudkms.googleapis.com"

  provisioner "local-exec" {
    command = <<EOF
for i in {1..5}; do
  sleep $i
  if gcloud services list --project="${google_project.demo.project_id}" | grep "cloudkms.googleapis.com"; then
    exit 0
  fi
done

echo "Service was not enabled after 15s"
exit 1
EOF
  }

[paddycarver]

I'd be 👍 to adding some polling to the service enable function. We could, conceivably, just drop an extra poll-until-present into https://github.com/terraform-providers/terraform-provider-google/blob/e58e099b1adb893333b5974c7438b88415acab8a/google/resource_google_project_services.go#L202-L209.

[danawillow]

Hey @sethvargo, your config has the key ring dependent on the project, so it's going to be created in parallel with the API enablement from the project service resource. I'd recommend adding a depends_on clause to the resource, or creating a dependency via interpolation.

I'm going to go ahead and close this since I don't think it's a real bug, but if my suggestion doesn't work let me know and I'll reopen it.

[sethvargo]

Hi @danawillow

I think you're mis-understanding. API enablement is an asynchronous call. I do have explicit depends_on in my config, and it still fails. The API call does not block while the service enablement happens, which is the feature I'm requesting we add. The project_service resource shouldn't return until the service is actually _enabled_. Currently it returns on successful API call, but that doesn't mean the service is ready.

[tammersaleh]

I just ran into this, and would love to see this issue reopened. @sethvargo is correct - the issue is that the google_project_services resource is considered complete when the API returns, but the API is returning prematurely (async). google_project_services should poll after create to block until those services are actually in place.

@sethvargo's local-exec trick is nifty, but hard to extrapolate when using google_project_services to enable multiple services at a time (and it doesn't work when handing explicit credentials to the google provider).

[tammersaleh]

...and now I just saw that this was addressed in #1524. I'll upgrade - sorry for the noise.

[hashibot[bot]]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!