In the event that an unexpected state is returned from
`environmentStateRefreshFunc` errors in the Elastic Beanstalk console
will not be returned to the user.
There is not azurerm_container_service.linux_profile.ssh_keys argument, as stated in the examples, but an ssh_key field. Arguments reference was correct.
To aid in tracking down the error that's causing
TestAccGoogleSqlDatabaseInstance_basic to fail (it's claiming an op
can't be found?) I've added the op name (which is unique) to the error
output for op errors.
Our GCP storage tests are really flaky right now due to rate limiting.
In theory, this could also impact Terraform users that are
deleting/creating large numbers of Google Cloud Storage buckets at once.
To fix, I'm detecting the specific error code that GCP returns when it's
a rate limit error, and using that with resource.Retry to try the
request again.
* helper/schema: Add custom Timeout block for resources
* refactor DefaultTimeout to suuport multiple types. Load meta in Refresh from Instance State
* update vpc but it probably wont last anyway
* refactor test into table test for more cases
* rename constant keys
* refactor configdecode
* remove VPC demo
* remove comments
* remove more comments
* refactor some
* rename timeKeys to timeoutKeys
* remove note
* documentation/resources: Document the Timeout block
* document timeouts
* have a test case that covers 'hours'
* restore a System default timeout of 20 minutes, instead of 0
* restore system default timeout of 20 minutes, refactor tests, add test method to handle system default
* rename timeout key constants
* test applying timeout to state
* refactor test
* Add resource Diff test
* clarify docs
* update to use constants
Starting with Go 1.8 betas, we've periodically received SIGQUITs on our
tests in Travis. The stack trace looks like this:
https://gist.github.com/mitchellh/abf09b0980f8ea01269f8d9d6133884d
The tests are timing out! This is a test that hasn't been touched really
in a very long time and has always passed. I've **reproduced this
locally** by setting `GOMAXPROCS=1` and running the test. By yielding
the scheduler in the hot loop, it now passes almost instantly every
time.
Perhaps the test can be written in a different way, but this gets tests
passing and I think will fix our periodic errors.
Joe Topjian