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
When using load balancer rules on an IP associated with a network
instead of a vpc, the network field can be omitted and inferred from the
IP. Filling this into state on read causes a spurious diff.
The openfirewall flag defaults to true when used on a network IP.
Implicit resource creation doesn't fit the terraform model, so we
disable it.
Also added a test which shows arguments that can be changed without
creating a new resource.
Previously the plan summary output would consider -/+ diffs as changes
even though they actually destroy and create instances. This was
misleadning and inconsistent with the accounting that gets done for the
similar summary written out after "apply".
Instead we now count the -/+ diffs as both adds and removes, which should
mean that the counts output in the plan summary should match those in
the apply summary, as long as no errors occur during apply.
This fixes#3163.
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.
Paul Hinze