* Add Triton Metadata modification AccTest.
The test starts the basic machine and then adds the metadata field
user_data.
Test fails if the user_data field does not match what we expect
OR it times out.
Related to hashicorp/terraform#6148
* Fix the non-convergence of Triton metadata changes
The code waiting for the entire Machine Metadata to "deep equal" the Terraform
metadata modifications. These two sets will only be the same if the user
changes all metadata fields of the resource before calling `apply`.
Closeshashicorp/terraform#6148
* provider/aws: Fix hashing on CloudFront certificate parameters
Adding necessary type assertion to values on the viewer_certificate hash
function to ensure that certain fields are indeed not zero string
values, versus simply zero interface{} values (aka nil, as is such for a
map[string]interface{}).
* provider/aws: CloudFront complex structure error handling
Handle errors better on calls to d.Set() in the
aws_cloudfront_distribution, namely in flattenDistributionConfig(). Also
caught a bug in the setting of the origin attribute, was incorrectly
attempting to set origins.
* provider/aws: Pass pointers to set CloudFront primitives
Change a few d.Set() for primitives in aws_cloudfront_distribution and
aws_cloudfront_origin_access_identity to use the pointer versus a
dereference.
* docs: Fix CloudFront examples formatting
Ran each example thru terraform fmt to fix indentation.
* provider/aws: Remove delete retention on CloudFront tests
To play better with Travis and not bloat the test account with disabled
distributions.
Disable-only functionality has been retained - one can enable it with
the TF_TEST_CLOUDFRONT_RETAIN environment variable.
* provider/aws: CloudFront delete waiter error handling
The call to resourceAwsCloudFrontDistributionWaitUntilDeployed() on
deletion of CloudFront distributions was not trapping error messages,
causing issues with waiter failure.
hil.Eval() now returns (hil.EvaluationResult, error) instead of (value,
type, error). This commit updates the call sites, but retains all
previous behaviour. Tests are also updated.
This commit patches a few acceptance tests in order to get them to
pass under OpenStack Mitaka.
The devstack dev environment script has also been updated to reflect
OpenStack Mitaka as well as the new Terraform dependency vendoring.
* provider/fastly: Add support for managing Headers
Adds support for managing Headers in a Fastly configuration.
* update acc test
* update website with example of adding a header block
* provider/aws: Default Network ACL resource
Provides a resource to manage the default AWS Network ACL. VPC Only.
* Remove subnet_id update, mark as computed value. Remove extra tag update
* refactor default rule number to be a constant
* refactor revokeRulesForType to be revokeAllNetworkACLEntries
Refactor method to delete all network ACL entries, regardless of type. The
previous implementation was under the assumption that we may only eliminate some
rule types and possibly not others, so the split was necessary.
We're now removing them all, so the logic isn't necessary
Several doc and test cleanups are here as well
* smite subnet_id, improve docs
According to the libpq documentation, "prefer" is the default in the
underlying library and so setting a different default in the Terraform
layer would be a breaking change for existing users of this provider
whose servers do not have TLS correctly configured.
The docs now link to the libpq manual's discussion of the security
implications of each of the ssl_mode options, so the user can understand
the limitations of the "prefer" default and can make an informed decision
about which setting is appropriate for their situation.
As with several other sensitive values in Opsworks, the API returns a
placeholder value rather than a nil. To avoid writing the placeholder
value into the state we just skip updating the password on read, letting
whatever value was in the state persist.
This means that Terraform can't detect configuration drift where someone
has changed the password via some other means, but Terraform will still
be able to recognize changes to the password made within Terraform itself
due to the "last-written" value in the state.
This fixes#6192.
Mitchell Hashimoto