This should make tests more stable going forward. Also switch out the
image used from Ubuntu to Alpine Linux to reduce required download size
during test runs.
Conflicts:
builtin/providers/google/provider.go
builtin/providers/google/resource_subscription.go
builtin/providers/google/resource_subscription_test.go
golang pubsub SDK has been released. moved topics/subscriptions to use that
Conflicts:
builtin/providers/google/provider.go
builtin/providers/google/resource_subscription.go
builtin/providers/google/resource_subscription_test.go
file renames and add documentation files
remove typo'd merge and type file move
add to index page as well
only need to define that once
remove topic_computed schema value
I think this was used at one point but is no longer. away.
cleanup typo
adds a couple more config values
- ackDeadlineSeconds: number of seconds to wait for an ack
- pushAttributes: attributes of a push subscription
- pushEndpoint: target for a push subscription
rearrange to better match current conventions
respond to all of the comments
PR #3896 added support for passing keys by content, but in this same PR
all references to `path.Join()` where changed to `filepath.join()`.
There is however a significant difference between these two calls and
using the latter one now causes issues when running the Chef
provisioner on Windows (see issue #4039).
Some error-checking was omitted.
Specifically, the cloudTrailSetLogging call in the Create function was
ignoring the return and cloudTrailGetLoggingStatus could crash on a
nil-dereference during the return. Fixed both.
Fixed some needless casting in cloudTrailGetLoggingStatus.
Clarified error message in acceptance tests.
Removed needless option from example in docs.
The default for `enable_logging`, which defines whether CloudTrail
actually logs events was originally written as defaulting to `false`,
since that's how AWS creates trails.
`true` is likely a better default for Terraform users.
Changed the default and updated the docs.
Changed the acceptance tests to verify new default behavior.
Previously we assumed the existence of some default objects that most
Opsworks users have because the Opsworks console creates them by default
when a new stack is created.
However, that meant that these tests wouldn't work correctly for anyone
who either had never used Opsworks via the UI or who had never accepted
the default of having the console create some predefined IAM objects to
use. It may also have led to some weird failures if a particular user had
customized the settings for these default objects.
Now the tests create suitable IAM roles, a policy and an instance profile
and use these when creating Opsworks stacks, avoiding any dependency
on any pre-existing objects.
This fixes#3998.
James Nugent