* master:
Update CHANGELOG.md
Update CHANGELOG.md
Added affinity group resource.
update link to actually work
provider/azure: Fix SQL client name to match upstream
add warning message to explain scenario of conflicting rules
typo
remove debugging
Update CHANGELOG.md
provider/aws: Add docs for autoscaling_policy + cloudwatch_metric_alarm
provider/aws: Add autoscaling_policy
provider/aws: Add cloudwatch_metric_alarm
rename method, update docs
clean up some conflicts with
clean up old, incompatible test
update tests with another example
update test
remove meta usage, stub test
fix existing tests
Consider security groups with source security groups when hashing
This is an iteration on the great work done by @dalehamel in PRs #2095
and #2109.
The core team went back and forth on how to best model Spot Instance
Requests, requesting and then rejecting a separate-resource
implementation in #2109.
After more internal discussion, we landed once again on a separate
resource to model Spot Instance Requests. Out of respect for
@dalehamel's already-significant donated time, with this I'm attempting
to pick up the work to take this across the finish line.
Important architectural decisions represented here:
* Spot Instance Requests are always of type "persistent", to properly
match Terraform's declarative model.
* The spot_instance_request resource exports several attributes that
are expected to be constantly changing as the spot market changes:
spot_bid_status, spot_request_state, and instance_id. Creating
additional resource dependencies based on these attributes is not
recommended, as Terraform diffs will be continually generated to keep
up with the live changes.
* When a Spot Instance Request is deleted/canceled, an attempt is made
to terminate the last-known attached spot instance. Race conditions
dictate that this attempt cannot guarantee that the associated spot
instance is terminated immediately.
Implementation notes:
* This version of aws_spot_instance_request borrows a lot of common
code from aws_instance.
* In order to facilitate borrowing, we introduce `awsInstanceOpts`, an
internal representation of instance details that's meant to be shared
between resources. The goal here would be to refactor ASG Launch
Configurations to use the same struct.
* The new aws_spot_instance_request acc. test is passing.
* All aws_instance acc. tests remain passing.
* upstream/master: (21 commits)
fix typo
fix typo, use awslabs/aws-sdk-go
Update CHANGELOG.md
More internal links in template documentation.
providers/aws: Requires ttl and records attributes if there isn't an ALIAS block.
Condense switch fallthroughs into expr lists
Fix docs for aws_route53_record params
Update CHANGELOG.md
provider/aws: Add IAM Server Certificate resource
aws_db_instance docs updated per #2070
providers/aws: Adds link to AWS docs about RDS parameters.
Downgrade middleman to 3.3.12 as 3.3.13 does not exist
providers/aws: Clarifies db_security_group usage.
"More more" no more!
Indentation issue
Export ARN in SQS queue and SNS topic / subscription; updated tests for new AWS SDK errors; updated documentation.
Changed Required: false to Optional: true in the SNS topic schema
Initial SNS support
correct resource name in example
added attributes reference section for AWS_EBS_VOLUME
...
aws hides its credentials in many places:
multiple env vars, config files,
ec2 metadata.
Terraform currently recognizes only the env vars;
to use the other options, you had to put in a
dummy empty value for access_key and secret_key.
Rather than duplicate all aws checks, ask the
aws sdk to fetch credentials earlier.
- Users
- Groups
- Roles
- Inline policies for the above three
- Instance profiles
- Managed policies
- Access keys
This is most of the data types provided by IAM. There are a few things
missing, but the functionality here is probably sufficient for 95% of
the cases. Makes a dent in #28.
Mitchell Hashimoto