* Update container_cluster.html.markdown
Just a more clear explanation of what happens when this field is not provided, since there was already an issue with this topic.
* Update container_cluster.html.markdown
Cleared extra comma.
* Use errwrap to retain original error
* Use built-in Page function, only return names when listing services
This removes the custom logic on pagination and uses the built-in Page function in the SDK to make things a bit simpler. Additionally, I added a field filter to only return service names, which drastically reduces the size of the API call (important for slow connections, given how frequently this function is executed).
Also added errwrap to better trace where errors originate.
* Add helper function for diffing string slices
This just looked really nasty inline
* Batch 20 services at a time, handle precondition failed, better errwrap
This commit does three things:
1. It batches services to be enabled 20 at a time. The API fails if you try to enable more than 20 services, and this is documented in the SDK and API. I learned this the hard way. I think Terraform should "do the right thing" here and batch them in series' of twenty, which is what this does. Each batch is tried in serial, but I think making it parallelized is not worth the complexity tradeoffs.
2. Handle the precondition failed error that occurs randomly. This just started happened, but it affects at least two APIs consistently, and a rudimentary test showed that it failed 78% of the time (78/100 times in an hour). We should fix this upstream, but that failure rate also necessitates (in my opinion) some mitigation on the Terraform side until a fix is in place at the API level.
3. Use errwrap on errors for better tracing. It was really difficult to trace exactly which error was being throw. That's fixed.
* Updates from code review
* Add "server_ca_cert" Attribute reference
Documents the addition of the `server_ca_cert` attribute for use in configuring SSL with GCP SQL Instances - added in PR #1020
* Updated formatting
Updates formatting to match the above fields.
* Add basic update for `google_kms_crypto_key` resource
Prior to this commit, any changes to `rotation_period` would
force a new resource as no `Update` was defined for the resource.
This commit introduces a basic `Update` through calling the
`Patch` service method. It only modifies the `rotation_period`,
and `next_rotation_time` at the moment, but this is reflective
of what is "allowed" on https://console.cloud.google.com/security/kms.
* Remove unused `Purpose` value in `CryptoKey`
We are only patching the `rotation_period`, and `next_rotation_time`,
so that value will not be affected.
* nit: format `Patch` operation to be in a single line
* Extend `TestAccKmsCryptoKey_rotation` test steps
- Test change in rotation period
- Test removal of rotation period
* Do not parse `NextRotationTime` if it is not set
* remove ForceNew: false
When creating a trigger by using the project defined in the schema we
enforce that the repo must be in that same project. We should be looking
at the project defined in the trigger_template data and falling back to
that first project if not found.
Closes: #1555
When enabling services, after the waiter returns, list the enabled
services and ensure the ones we enabled are in there. If not, retry. May
not always resolve#1393, but should help. Unfortunately, the real
answer is probably either:
1. For us to try and get the API updated to only return the waiter when
the service will consistently be available. I don't know how feasible
this is, but I'm willing to open a ticket.
2. For us to build retries into ~all our resources to retry for a set
amount of time when a service not enabled error is returned. This would
greatly slow down the provider in the case of the service legitimately
not being enabled, but is how other providers handle this class of
problem.
Unfortunately, due to the eventual consistency at play, this is a hard
issue to reproduce and prove, though it matches with my
experience--while testing this patch, one of the tests failed with the
error that the serviceusage API hadn't been enabled, but only on step 4
of the test, when calls had already succeeded. Which suggests eventual
consistency, to me. Regardless, this patch shouldn't _hurt_ and should
mostly be an imperceptible change to users, and should make instances
like #1393 less likely.
* vendor service usage api
* use serviceusage api instead of servicemanagement for project services
* add bigquery-json to test
* add import for project service
* add serviceusage_operation.go
