Fixes#8468
If a user wished to bump the `engine_version` of an RDS instance,
Terraform was not sending `allow_major_version_upgrade` to the API
*unless* that value also changed at the same time. This caused the
following error from RDS API:
```
* aws_db_instance.bar: Error modifying DB Instance
* tf-20160825101420910562798obb: InvalidParameterCombination: The
* AllowMajorVersionUpgrade flag must be present when upgrading to a new
* major version.
status code: 400, request id: 20e36364-6ab0-11e6-b794-51f12f4135f1
```
This change will always send the `allow_major_version_upgrade` flag to
the API when the `engine_version` changes.
This still relies on the user setting the correct value i.e. if they are
upgrading from postgres 0.4.7 -> 9.5.2 then the config will need to set
the `allow_major_version_upgrade` flag to be `true`
false
Fixes#7035
A known issue in Terraform means that d.GetOk() on a bool which is false
will mean it doesn't get evaulated. Therefore, when people set
publicly_accessible to false, it will never get evaluated on the Create
We are going to make it default to false now
As requested in #4822, add support for a KMS Key ID (ARN) for Db
Instance
```
make testacc TEST=./builtin/providers/aws
TESTARGS='-run=TestAccAWSDBInstance_kmsKey' 2>~/tf.log
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v
-run=TestAccAWSDBInstance_kmsKey -timeout 120m
=== RUN TestAccAWSDBInstance_basic
--- PASS: TestAccAWSDBInstance_basic (587.37s)
=== RUN TestAccAWSDBInstance_kmsKey
--- PASS: TestAccAWSDBInstance_kmsKey (625.31s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 1212.684s
```
Needed to truncate the identifier for SQL Server engines to keep it at
max 15 chars per the docs. Not a full UUID going into it, but should be
"unique enough" to not matter in practice.
Modified the basic test to use the generated value. Other tests are
still working w/ explicitly specified identifiers.
of the database after creation. So we need to be able to
set the CharacterSetName on creation.
This is an option and will automagically default to
AL32UTF8.
The AWS SDK will give you an error message if you try to
apply this setting to other engines. The patch will only
report the character_set_name attribute, if CharacterSetName
is set on the instance.
Signed-off-by: Lars Bahner <lars.bahner@gmail.com>
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.
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
- Remove check on password for AWS RDS Instance
- Update documentation on AWS RDS Instance regarding DB Security Groups
- Change error handling to check error code from AWS API [ci skip]
Several of the arguments were optional, and if omitted, they are
calculated. Mark them as such in the schema to avoid triggering an
update.
Go back to storing the password in the state file. Without doing so,
there's no way for Terraform to know the password has changed. It should
be hashed, but then interpolating the password yields a hash instead of
the password.
Make the `name` parameter optional. It's not required in any engine, and
in some (MS SQL Server) it's not allowed at all.
Drop the `skip_final_snapshot` argument. If `final_snapshot_identifier`
isn't specified, then don't make a final snapshot. As things were, it
was possible to create a resource with neither of these arguments
specified which would later fail when it was to be deleted since the RDS
API requires exactly one of the two.
Resolves issue #689.
The Terraform configuration syntax defines what arrays are.
Use the word array consistently throughout the documentation
instead of list.
The corresponding JSON datatype is called array as well, and
since the Terraform configuration syntax is interoperable with
JSON it makes sense to use the term array to describe them.
Paul Stack