http and https SNS topic subscription endpoints require confirmation to set a valid arn otherwise
arn would be set to "pending confirmation". If the endpoints auto confirm then arn is set
asynchronously but if we try to create another subscription with same parameters then api returns
"pending subscription" as arn but does not create another a duplicate subscription. In order to
solve this we should be fetching the subscription list for the topic and identify the subscription
with same parameters i.e., protocol, topic_arn, endpoint and extract the subscription arn.
Following changes were made to support the http/https endpoints that auto confirms
1. Added 3 extra parameters i.e.,
1. endpoint_auto_confirms -> boolean indicates if end points auto confirms
2. max_fetch_retries -> number of times to fetch subscription list for the topic to get the subscription arn
3. fetch_retry_delay -> delay b/w fetch subscription list call as the confirmation is done asynchronously.
With these parameters help added support http and https protocol based endpoints that auto confirm.
2. Update website doc appropriately
This allows specification of the profile for the shared credentials
provider for AWS to be specified in Terraform configuration. This is
useful if defining providers with aliases, or if you don't want to set
environment variables. Example:
$ aws configure --profile this_is_dog
... enter keys
$ cat main.tf
provider "aws" {
profile = "this_is_dog"
# Optionally also specify the path to the credentials file
shared_credentials_file = "/tmp/credentials"
}
This is equivalent to specifying AWS_PROFILE or
AWS_SHARED_CREDENTIALS_FILE in the environment.
When spinning up from a snapshot or a read replica, these fields are
now optional:
* allocated_storage
* engine
* password
* username
Some validation logic is added to make these fields required when
starting a database from scratch.
The documentation is updated accordingly.
AWS does some funky stuff to handle all the variations in certificates that CA's like to hand out to users. This commit adds a note about this and details how to avoid issues. See #3837 for more information.
Only use the create_before_destroy-hook in launch configurations. The autoscaling group must not use the create_before_destroy-hook, because it can be updated (and not destroyed + re-created). Using the create_before_destroy-hook in autoscaling group also leads to unwanted cyclic dependencies.
also removed the notion of tags from the redshift security group and
parameter group documentation until that has been implemented
Redshift Cluster CRUD and acceptance tests
Removing the Acceptance test for the Cluster Updates. You cannot delete
a cluster immediately after performing an operation on it. We would need
to add a lot of retry logic to the system to get this test to work
Adding some schema validation for RedShift cluster
Adding the last of the pieces of a first draft of the Redshift work - this is the documentation
Changed the aws_redshift_security_group and aws_redshift_parameter_group
to remove the tags from the schema. Tags are a little bit more
complicated than originally though - I will revisit this later
Then added the schema, CRUD functionality and basic acceptance tests for
aws_redshift_subnet_group
Adding an acceptance test for the Update of subnet_ids in AWS Redshift Subnet Group
This action is almost exactly the same as creating a SimpleAD so we
reuse this resource and allow the user to specify the type when creating
the directory (ignoring the size if the type is MicrosoftAD).
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.
It's a bit confusing to have Terraform poll until instances come up on
ASG creation but not on update. This changes update to also poll if
min_size or desired_capacity are changed.
This changes the waiting behavior to wait for precisely the desired
number of instances instead of that number as a "minimum". I believe
this shouldn't have any undue side effects, and the behavior can still
be opted out of by setting `wait_for_capacity_timeout` to 0.
Adam Ochonicki