This covers the scenario of an instance created by a spot request. Using
Terraform we only know the spot request is fulfilled but the instance can
still be pending which causes the attachment to fail.
* provider/ignition: migration from resources to data resources
* website: provider/ignition documention updated to data resources
* provider/ignition: backwards compatibility support for old resources
* Ensures elb exists before negotiation policy check; Fixes#11260
* Adds acceptance test case for missing elb
* Adds back https properties for test elb
* vendor: Updating cobblerclient for Cobbler
* provider/cobbler: Fix Profile Repos
This commit fixes a bug where adding repos would result in an error.
This was due to the Cobbler API wanting a space-separated list of
repos rather than an array. The Cobbler Service will split the string
by space when used internally, but will always present the repos
as a string.
* provider/cobbler: System Interface Management Test
This commit adds a test to verify that the Management
parameter of System Interfaces works.
* Allow for local development with ns1 provider.
* Adds first implementation of ns1 notification list resource.
* NS1 record.use_client_subnet defaults to true, and added test for field.
* Adds more test cases for monitoring jobs.
* Adds webhook/datafeed notifier types and acctests for notifylists.
* Adds docs for notifylists resource.
* Updates ns1-go rest client via govendor
* Fix typos in record docs
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.
Matt Dainty