v1.17.0

fix: reserved instances, aurora rds specifics @oycyc (#249)

## what RDS Reserved Instances multi AZ mode is never available for Aurora engines, see images on the console - this PR checks to ensure that it is set to false if the engine is Aurora:  

why

That configuration isn't really applicable anyways since this statement from the AWS docs https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithReservedDBInstances.html:

references

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithReservedDBInstances.html

v1.16.0

fix: reserved instance multi_az setting @oycyc (#248)

## what

Using local.is_regional_cluster to determine whether or not it is Multi-AZ is not accurate. local.is_regional_cluster only checks if var.cluster_type == "regional", which determines if this is a regional vs global cluster

I could have a regional cluster, but it is NOT multi-az. One determining factor is how many instances in the cluster, if ever more than 1 in a single cluster, then it has to be in multiple AZs. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html

why

If I have a regional cluster, this thinks that it's ALWAYS multi-az, which is not true.

references

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html

v1.15.1

🚀 Enhancements

fix: reserved instances restrictions @oycyc (#244)

## what

This conditional check on whether or not to enable reserved instances is too restrictive. contains(["mysql", "postgresql"], local.reserved_instance_engine) is saying that only allow it if it is MySQL or PostgreSQL.

I think contains was originally meant to be like in the literal sense of "contains". Since in my case, I'm using aurora-postgresql, and it fails this check, yet it is one of the options for reserved instances.

why

endswith might be better, but it is TOO restrictive, seeing that there's so many options.

Additionally, Terraform will fail if user specifies the wrong engine type. There's no need for this check.

references

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/rds_reserved_instance_offering

🐛 Bug Fixes

fix: reserved instances restrictions @oycyc (#244)

## what

This conditional check on whether or not to enable reserved instances is too restrictive. contains(["mysql", "postgresql"], local.reserved_instance_engine) is saying that only allow it if it is MySQL or PostgreSQL.

I think contains was originally meant to be like in the literal sense of "contains". Since in my case, I'm using aurora-postgresql, and it fails this check, yet it is one of the options for reserved instances.

why

endswith might be better, but it is TOO restrictive, seeing that there's so many options.

Additionally, Terraform will fail if user specifies the wrong engine type. There's no need for this check.

references

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/rds_reserved_instance_offering

v1.15.0

🚀 Enhancements

• Implement and close #237 (add option for local write forwarding) Thank you @Junaid-Tem
• Implement and close #239 (allow the configuration of reservation_id for aws_rds_reserved_instance) Thank you @oycyc

🐛 Bug Fixes

• Partly revert #236 (see discussion below). Closes #241

Multiple cleanups @Nuru (#242)

## what

• Partly revert #236 (see discussion below)
• Allow explicitly naming parameter group
• Use full name of engine for reserved DB instances
• Implement and close #197
• Implement and close #199
• Implement and close #230 Thank you @raymondchen625

why

• Closes #241
• Closes #225
• Instance engine should match cluster engine
• Consolidate PRs

discussion: why partially revert #236?

PR #236 enhanced the random_pet that determines part of the name of the DB instances so that the name would change whenever the instances would need to be recreated. Unfortunately, as a side-effect, that causes all instances created with earlier versions of this module to be replaced.

Upon further investigation, it was determined that all the "keepers" added by the PR would also force the cluster to be replaced. Unlike replacing an instance, replacing the cluster results in data loss. Also, unless you change the name of the cluster, the module both before and after the PR would fail, because it would try to create a new cluster with the same name before destroying the old cluster.

We prefer this failure mode, requiring the user to explicitly destroy the cluster before creating the new one, because it puts the user on notice about the potential data loss. So given that the changes in the PR did not make something work that did not work before, and it did cause disruption, we reverted the change to the keepers.

v1.14.0

fix: reserved instance output @oycyc (#240)

## what

Fix the output

How it will look with this:

why

It does not need to be a join with a [*] this will cause error, just referring to it with the resource name will output everything as one object.

references

See the Terraform provider docs https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/rds_reserved_instance#attribute-reference

v1.13.0

Output instance endpoints, add attributes to `random_pet` that force a new instance @finchr (#236)

…new instance

what

• output instance endpoints
• add aws_rds_cluster_instance attributes that force a new instance to the randmon_pet resource.

why

• I need the actual instance endpoints for the Datadog DMS integration, the default dashboards work better with the exact instance identifier.
• Currently if any of these attributes change (db_subnet_group_name, engine) it will bypass the random_pet and attempt to create instances with the same identifier.

references

v1.12.0

bug/193-enable-http-endpoint @tsaucier0 (#234)

## what * Support for serverless v2 to ensure that configurations (like HTTP endpoints for the Data API) are correctly enabled on instances using the serverless v2 implementation. * A new condition, is_serverless_v2, was introduced to identify serverless v2 instances based on the specific configuration parameters required for its activation.

why

• The original code was intended to enable_http_endpoint based on whether the database instance was using serverless architecture. With the introduction of serverless v2 for certain database engines, there is a need to update the logic to accommodate these options.

references

Closes #193

v1.11.4

🐛 Bug Fixes

fix(reserved instances): use var.instance_type to determine RI offering instead of optional db_instance_class var @kevcube (#235)

the var `db_instance_class` isn't required, so won't always be available. `instance_type` is required.

v1.11.3

feat: support reserved instances @kevcube (#233)

## questions - do we want to allow customization of the count/size of reserved instances?

🤖 Automatic Updates

Update terratest to '>= 0.46.0' @osterman (#215)

## what - Update terratest `>= 0.46.0`

why

• Support OpenTofu for testing

References

• https://github.com/gruntwork-io/terratest/releases/tag/v0.46.0
• DEV-374 Add opentofu to all our Terragrunt Testing GHA matrix

v1.11.2

Dual stack support @ngoyal16 (#231)

## what

RDS cluster can be run in two network modes - IPV4 or DUAL.
Underlying module already supports this parameter

why

It can be mandatory to enable it to be able to connect from ipv6 only runtimes

references

Closes #175

🤖 Automatic Updates

Migrate new test account @osterman (#232)

## what - Update `.github/settings.yml` - Update `.github/chatops.yml` files

why

• Re-apply .github/settings.yml from org level to get terratest environment
• Migrate to new test account

References

• DEV-388 Automate clean up of test account in new organization
• DEV-387 Update terratest to work on a shared workflow instead of a dispatch action
• DEV-386 Update terratest to use new testing account with GitHub OIDC

Update .github/settings.yml @osterman (#229)

## what - Update `.github/settings.yml` - Drop `.github/auto-release.yml` files

why

• Re-apply .github/settings.yml from org level
• Use organization level auto-release settings

references

• DEV-1242 Add protected tags with Repository Rulesets on GitHub

Update .github/settings.yml @osterman (#228)

## what - Update `.github/settings.yml` - Drop `.github/auto-release.yml` files

why

• Re-apply .github/settings.yml from org level
• Use organization level auto-release settings

references

• DEV-1242 Add protected tags with Repository Rulesets on GitHub