v0.47.0

Ignore admin credentials for snapshots/replicated clusters @alexjurkiewicz (#119)

Fixes errors like:

Error: error creating RDS cluster: InvalidParameterCombination: Cannot specify user name for instance cluster replication cluster

v0.46.2

🤖 Automatic Updates

Update context.tf @cloudpossebot (#118)

what

This is an auto-generated PR that updates the context.tf file to the latest version from cloudposse/terraform-null-label

why

To support all the features of the context interface.

v0.46.1

🚀 Enhancements

added apply_immediately support to cluster_instance resource @RichardHeywood (#111)

what

• Add apply_immediately flag to the db instances

why

• Currently you can only apply changes immediately to the cluster resource. However the aws_rds_cluster_instance resource also supports the apply_immediately flag.
• Use case: Attempting to change the instance types for the RDS cluster causes the changes to be staged pending the next maintenance window. This change allows you to perform the updates before then.

v0.46.0

Ignore `engine_version` for rds instance in order to upgrade without recreating db instances @nitrocode (#115)

what

• Ignore engine_version for rds instance in order to upgrade

why

• When the engine_version for the aws_rds_cluster is changed and applied, the db instances will be upgraded.
• There is a note on the rds_cluster_instance#engine_version which states

  (Optional, Forces new resource) The database engine version. When managing the engine version in the cluster, it is recommended to add the lifecycle ignore_changes configuration for this argument to prevent Terraform from proposing changes to the instance engine version directly.

terraform plan

  # module.primary_aurora_postgres_cluster.aws_rds_cluster_instance.default[0] must be replaced
+/- resource "aws_rds_cluster_instance" "default" {
      + apply_immediately               = (known after apply)
      ~ arn                             = "arn:aws:rds:us-east-2:snip:db:snip-1" -> (known after apply)
      ~ availability_zone               = "us-east-2c" -> (known after apply)
      ~ ca_cert_identifier              = "rds-ca-2019" -> (known after apply)
      ~ dbi_resource_id                 = "db-snip" -> (known after apply)
      ~ endpoint                        = "snip-1.snip.us-east-2.rds.amazonaws.com" -> (known after apply)
      ~ engine_version                  = "12.4" -> "12.6" # forces replacement
      ~ id                              = "snip-1" -> (known after apply)
      + identifier_prefix               = (known after apply)
      ~ kms_key_id                      = "arn:aws:kms:us-east-2:snip:key/snip" -> (known after apply)
      + monitoring_role_arn             = (known after apply)
      + performance_insights_kms_key_id = (known after apply)
      ~ port                            = 5432 -> (known after apply)
      ~ preferred_backup_window         = "07:00-09:00" -> (known after apply)
      ~ preferred_maintenance_window    = "sun:07:32-sun:08:02" -> (known after apply)
      ~ storage_encrypted               = true -> (known after apply)
      ~ writer                          = true -> (known after apply)
        # (13 unchanged attributes hidden)
    }

terraform apply (error)

module.primary_aurora_postgres_cluster.aws_rds_cluster_instance.default[0]: Creating...
╷
│ Error: error creating RDS Cluster (snip) Instance: DBInstanceAlreadyExists: DB Instance already exists
│ 	status code: 400, request id: snip
│ 
│   with module.primary_aurora_postgres_cluster.aws_rds_cluster_instance.default[0],
│   on main.tf line 206, in resource "aws_rds_cluster_instance" "default":
│  206: resource "aws_rds_cluster_instance" "default" {
│ 
╵

terraform plan (no changes)

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform
apply":

  # module.primary_aurora_postgres_cluster.aws_rds_cluster_instance.default[0] has been changed
  ~ resource "aws_rds_cluster_instance" "default" {
      ~ engine_version               = "12.4" -> "12.6"
        id                           = "snip-1"
        # (24 unchanged attributes hidden)
    }

Unless you have made equivalent changes to your configuration, or ignored the relevant
attributes using ignore_changes, the following plan may include actions to undo or respond to
these changes.

No changes. Your infrastructure matches the configuration.

Confirmed in the AWS console that the postgres aurora rds instance and cluster are 12.6.

references

N/A

v0.45.0

allow major version upgrades @kevcube (#113)

what

• enables upgrading major versions (closes #87)

why

• sometimes ya gotta upgrade major versions

references

• #87
• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/rds_cluster#allow_major_version_upgrade

v0.44.2

🚀 Enhancements

fix: 🐛 adjust engine version in docs and readme to aurora-mysql @sheldonhull (#112)

what

Prior value was invalid according to aws docs when trying to create a aurora-mysql based instance.

AWS Terraform Provider docs indicated:

engine - (Optional) The name of the database engine to be used for this DB cluster. Defaults to aurora. Valid Values: aurora, aurora-mysql, aurora-postgresql

Since the examples I used were to deploy aurora-mysql the engine should be set to this as well when the cluster family is set as follows:

engine  = "aurora-mysql"
cluster_family  = "aurora-mysql5.7"

why

Adjust to aurora-mysql and this resolved the failure to deploy a new cluster based on the mysql engine.

v0.44.1

🚀 Enhancements

create_before_destroy for parameter groups, explicit dependencies @Nuru (#110)

what

• Make parameter groups create_before_destroy
• Add explicit dependencies

why

• You cannot delete a parameter group while it is in use, but you can update a database with a new parameter group, so in order to change parameter groups, you need to create a new one, install it, then delete the old one.
• Some update and destroy operations were failing because resources were being deleted in the wrong order.

v0.44.0

Be explicit about creating a regional (standalone) cluster or one part of a Global cluster @Nuru (#109)

what

• replace make_primary_cluster with cluster_type

why

• The name "make_primary_cluster" was very misleading

v0.43.0

The variable introduced in this release (make_primary_cluster) was poorly named, leading to significant confusion. It was replaced with a new variable, cluster_type, in the next release. Therefore this release is not recommended for use.

Be explicit about primary/secondary cluster @Nuru (#108)

what

• Allow user to specify explicitly whether or not this should create a primary or secondary cluster

why

• Implicit selection based on global_cluster_identifier fails if the global cluster is being created at the same time as the primary and/or secondary cluster

v0.42.1

🤖 Automatic Updates

Update Terraform cloudposse/route53-cluster-hostname/aws to v0.12.0 @renovate (#106)

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/route53-cluster-hostname/aws (source)	terraform	minor	0.11.0 -> 0.12.0

---

Release Notes

cloudposse/terraform-aws-route53-cluster-hostname

v0.12.0

Compare Source

context.tf updated to v0.24.1, minimum required Terraform version bumped to 0.13.0 when needed, readme updated @​maximmi (#​35)

##### what - update context.tf to v0.24.1 - minimum required Terraform version bumped to 0.13.0 - readme updated, Bridgecrew compliance badges added ##### why - It allows for setting the letter case of tag names and labels, back compatibility with context v0.22.0 and below - we have dropped support for Terraform 0.12 - To be able see and fix the recommendations from Bridgecrew so we can position our modules as standards compliant