A "Layer" is a particular service that forms part of the infrastructure for
a set of applications. Some layers are application servers and others are
pure infrastructure, like MySQL servers or load balancers.
Although the AWS API only has one type called "Layer", it actually has
a number of different "soft" types that each have slightly different
validation rules and extra properties that are packed into the Attributes
map.
To make the validation rule differences explicit in Terraform, and to make
the Terraform structure more closely resemble the OpsWorks UI than its
API, we use a separate resource type per layer type, with the common code
factored out into a shared struct type.
"Stack" is the root concept in OpsWorks, and acts as a container for a number
of different "layers" that each provide some service for an application.
A stack isn't very interesting on its own, but it needs to be created before
any layers can be created.
* 'master' of github.com:hashicorp/terraform:
Update CHANGELOG.md
Changing the ElastiCache Cluster configuration_engine to be on the cluster, not on the cache nodes
Adding configuration endpoint to the elasticache cluster nodes
When launching a new RDS instance in a VPC-default AWS account, trying to control which VPC the new RDS instance lands in is not apparent from the parameters available.
The following works:
```
resource "aws_db_subnet_group" "foo" {
name = "foo"
description = "DB Subnet for foo"
subnet_ids = ["${aws_subnet.foo_1a.id}", "${aws_subnet.foo_1b.id}"]
}
resource "aws_db_instance" "bar" {
...
db_subnet_group_name = "${aws_db_subnet_group.foo.name}"
...
}
```
Hopefully this doc update will help others
AWS provides three different ways to create AMIs that each have different
inputs, but once they are complete the same management operations apply.
Thus these three resources each have a different "Create" implementation
but then share the same "Read", "Update" and "Delete" implementations.
The Elasticache API accepts a mixed-case subnet name on create, but
normalizes it to lowercase before storing it. When retrieving a subnet,
the name is treated as case-sensitive, so the lowercase version must be
used.
Given that case within subnet names is not significant, the new StateFunc
on the name attribute causes the state to reflect the lowercase version
that the API uses, and changes in case alone will not show as a diff.
Given that we must look up subnet names in lower case, we set the
instance id to be a lowercase version of the user's provided name. This
then allows a later Refresh call to succeed even if the user provided
a mixed-case name.
Previously users could work around this by just avoiding putting uppercase
letters in the name, but that is often inconvenient if e.g. the name is
being constructed from variables defined elsewhere that may already have
uppercase letters present.
* master: (84 commits)
provider/aws: Update to aws-sdk 0.9.0 rc1
use name instead of id - launch configs use the name and not ID
Fix typo on heroku_cert example
provider/aws: add value into ELB name validation message
tests: fix missed test update from last merge
update prevent_destroy error message
Update CHANGELOG.md
Update CHANGELOG.md
providers/aws: Update Launch Config. docs to detail naming and lifecycle recommendation
release: cleanup after v0.6.3
v0.6.3
Update CHANGELOG.md
core: fix deadlock when dependable node replaced with non-dependable one
tests: extract deadlock checking test helper
core: log every 5s while waiting for dependencies
Fixed indentation in a code sample
state/remote/s3: match with upstream changes
provider/aws: match with upstream changes
google: Add example of two-tier app
Updating Launch Config Docs for Name attribute
...
* upstream/master:
Update CHANGELOG.md
Update CHANGELOG.md
provider/aws: allow external ENI attachments
Update AWS provider documentation
docs/aws: Fix example of aws_iam_role_policy
provider/aws: S3 bucket test that should fail
provider/aws: Return if Bucket not found
Update CHANGELOG.md
Update CHANGELOG.md
helper/schema: record schema version when destroy fails
settings file is not required
provider/azure: Allow settings_file to accept XML string
add note to aws_iam_policy_attachment explaining its use/limitations
docs: clarify template_file path information
google: Sort resources by alphabet in docs
Support go get in go 1.5
Update CHANGELOG.md
aws_network_interface attachment block is not required
provider/aws: Fix issue in Security Group Rules where the Security Group is not found
This commit exports the `arn` as well as the `id`, since IAM
roles require the full resource name rather than just the table
name. I'd even be in favor or having `arn` as the `id` since the
<region, tablename> pair is the uniqueness constraint, but this
will keep backwards compatibility:
http://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateTable.html
* master: (720 commits)
Update CHANGELOG.md
Update CHANGELOG.md
dynamodb-local Update AWS config https://github.com/hashicorp/terraform/pull/2825#issuecomment-126353610
Make target_pools optional
Update CHANGELOG.md
code formatting
Update CHANGELOG.md
providers/google: Fix reading account_file path
providers/google: Fix error appending
providers/google: Return if we could parse JSON
providers/google: Change account_file to JSON
providers/google: Default account_file* to empty
providers/google: Add account_file/account_file_contents ConflictsWith
providers/google: Document account_file_contents
providers/google: Use account_file_contents if provided
providers/google: Add account_file_contents to provider
Update CHANGELOG.md
Update CHANGELOG.md
dynamodb-local Use ` instead of : to refer region to keep the consistency with the provider docs
dynamodb-local Update aws provider docs to include the `dynamodb_endpoint` argument
...
* master: (86 commits)
providers/google: Fix reading account_file path
providers/google: Fix error appending
providers/google: Return if we could parse JSON
providers/google: Change account_file to JSON
providers/google: Default account_file* to empty
providers/google: Add account_file/account_file_contents ConflictsWith
providers/google: Document account_file_contents
providers/google: Use account_file_contents if provided
providers/google: Add account_file_contents to provider
Update CHANGELOG.md
Update CHANGELOG.md
use d.Id()
Update CHANGELOG.md
Update CHANGELOG.md
scripts: change website_push to push from HEAD
update analytics
core: fix crash on provider warning
provider/aws: Update source to comply with upstream breaking change
Update CHANGELOG.
provider/aws: Fix issue with IAM Server Certificates and Chains
...
`aws_iam_access_key` resource is not supported `status` field.
Example from https://www.terraform.io/docs/providers/aws/r/iam_access_key.html:
resource "aws_iam_access_key" "lb" {
user = "${aws_iam_user.lb.name}"
status = "Active"
}
resource "aws_iam_user" "lb" {
name = "loadbalancer"
path = "/system/"
}
Result:
$ terraform plan
There are warnings and/or errors related to your configuration. Please
fix these before continuing.
Errors:
* aws_iam_access_key.lb: "status": this field cannot be set
* 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.
When a user tried to create an `aws_network_interface` resource without specifying the `private_ips` or `security_groups` attributes the API call to AWS would fail with a 500 HTTP error. Length checks have been put in place for both of these attributes before they are added to the `ec2.CreateNetworkInterfaceInput` struct.
Documentation was also added for the `aws_network_interface` resource.
When using `-1` for the protocol, both `from_port` and `to_port` must be `0`, or so says AWS thru Terraform:
```
* from_port (0) and to_port (65535) must both be 0 to use the the 'ALL' "-1" protocol!
```
db_security_group is only intended to be used in EC2-Classic Platform.
For DB instances in a VPC, we associate VPC security groups instead,
when declaring the db_instance resource.
* ctiwald/ct/fix-protocol-problem:
aws: Document the odd protocol = "-1" behavior in security groups.
aws: Fixup structure_test to handle new expandIPPerms behavior.
aws: Add security group acceptance tests for protocol -1 fixes.
aws: error on expndIPPerms(...) if our ports and protocol conflict.
Radek Simko