v0.48.1

🚀 Enhancements

Update AWS provider minimum version @alexjurkiewicz (#125)

what

• c96d859 added performance_insights_retention_period, which is supported in AWS provider v3.63.0 onwards.

why

• Prevent issues with older cached aws providers

references

N/A

v0.48.0

Additional inputs @nitrocode (#124)

what

• Add performance_insights_retention_period
• Add ca_cert_identifier
• Add preferred_maintenance_window to instances
• Add timeout to instances

why

• Performance insights retention
• Add a ca cert identifier
• Put the maintenance window on cluster and instances
• Allow rds instances to be created without hitting a timeout

v0.47.2

🤖 Automatic Updates

chore(deps): update terraform cloudposse/label/null to v0.25.0 @renovate (#122)

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/label/null (source)	module	minor	0.24.1 -> 0.25.0

---

Release Notes

cloudposse/terraform-null-label

v0.25.0

Compare Source

Add "tenant", "labels_as_tags", and "descriptors" @​Nuru (#​132)

##### what - Add additional label and `id` component: `tenant` - New input `labels_as_tags` controls which labels are exported as tags - New input `descriptor_formats` generates new output `descriptors` - Update README, remove link to obsolete `terraform-terraform-label` ##### why - Support users that host resources on behalf of and/or dedicated to single customers - Supersedes and closes #​131, giving people control over which tags the module generates - Simple mechanism for creating multiple identifiers from the same inputs, reducing the need to create multiple instances of `null-label` - Document `tenant`, `labels_as_tags`, `descriptor_formats`, add additional clarification, stop promoting obsolete module

Fix: Update README Snippets @​korenyoni (#​130)

##### what * Update README snippets to reflect use of Terraform Registry. ##### why * Including snippets that reflect use of the Terraform Registry make it easier for users to quickly instantiate a null_label module. * README is out of date and does not include snippets that reflect use of the Terraform Registry. ##### references * N/A

Bridgecrew compliance @​Nuru (#​125)

##### what - Resolve Bridgecrew compliance complaint about example Autoscaling Group (BC_AWS_GENERAL_31) - Fix typo in README - Include Terraform lock file in `.gitignore` ##### why - Get clean Bridgecrew badge - Correct confusing error - Ensure lock files are not checked into GitHub ##### note The PR can and should be merged into `master` to update README and Bridgecrew without triggering a new release/version. These changes have no effect on the actual module in use and a release will create unnecessary ripple effects. However, merging to `master` will update the README and badges, so is worthwhile, and the changes will move forward into the next release.

Properly output descriptors of chained modules @​Nuru (#​133)

##### what - Properly output descriptors of chained modules ##### why - Bug fix; implement intended behavior

---

Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box.

---

This PR has been generated by WhiteSource Renovate. View repository job log here.

v0.47.1

🤖 Automatic Updates

chore(deps): update terraform cloudposse/route53-cluster-hostname/aws to v0.12.2 @renovate (#121)

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/route53-cluster-hostname/aws (source)	module	patch	0.12.0 -> 0.12.2

---

Release Notes

cloudposse/terraform-aws-route53-cluster-hostname

v0.12.2

Compare Source

🚀 Enhancements

Bump AWS provider 3.0 @​nitrocode (#​36)

##### what * Bump AWS provider 3.0 ##### why * Downstream modules can take advantage of the more recent aws provider ##### references N/A

v0.12.1

Compare Source

🚀 Enhancements

Chore: run `make github/init` @​korenyoni (#​37)

##### what * Run `make github/init`. ##### why * Updates GHA-workflow-related files to their latest distribution. * The old `context.tf` distribution is incompatible with the `tenant` label. ##### references * https://github.com/cloudposse/terraform-null-label/releases/tag/0.25.0

---

Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box.

---

This PR has been generated by WhiteSource Renovate. View repository job log here.

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.