Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: allow the creation of cross-region rds replicas #346

Merged

Conversation

riccardo-salamanna
Copy link
Contributor

Description

The changes adds a boolean called cross_region_replica.

Motivation and Context

In order to create a cross-region replica, we should specify a target subnet group, which is not needed for a same-region replica, as your module already supports with no issues. The idea is to set the cross_region_replica variable to true to allow the creation of the needed subnet group with minor changes to the source code

Breaking Changes

none

How Has This Been Tested?

i've tested this on both a same region and cross region replica.

@antonbabenko
Copy link
Member

Hi!

How about changing the variable name from single-purpose var.cross_region_replica to a more general like - var.create_db_subnet_group with default = true (as it is now) ?

The reason for this change is that there can be other situations where it makes sense to disable the creation of db_subnet_group in the future (if not already).

@riccardo-salamanna
Copy link
Contributor Author

riccardo-salamanna commented Jun 28, 2021

Hi @antonbabenko thanks for your quick reply. I'm editing my comment cause i know understood what you mean :)

So yes i can do it as you say, but i do think if we re use var.create_db_subnet_group, we will not be able to use an existing subnet group without creating one, please correct me if i am wrong

Copy link
Member

@antonbabenko antonbabenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to ask what @bryantbiggs thinks about the name for cross_region_replica variable and this PR?

main.tf Outdated
@@ -1,6 +1,6 @@
locals {
master_password = var.create_db_instance && var.create_random_password ? random_password.master_password[0].result : var.password
db_subnet_group_name = var.replicate_source_db != null ? null : coalesce(var.db_subnet_group_name, module.db_subnet_group.db_subnet_group_id, var.identifier)
db_subnet_group_name = var.cross_region_replica != true && var.replicate_source_db != null ? null : coalesce(var.db_subnet_group_name, module.db_subnet_group.db_subnet_group_id, var.identifier)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bryantbiggs local.db_subnet_group_name does not seem to be used in module db_subnet_group on line 24. Is it correct?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct - we only create the subnet group when create_db_subnet_group = true and the name is either db_subnet_group_name or identifier.

then, based on the logic on line 3 - we provide the subnet group name to the instance itself

db_subnet_group_name = local.db_subnet_group_name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah the issue is that if want to create a read only replica, db_subnet_group_name defaults to null, which is necessary for same region replicas but it is not correct for cross-region (different vpc, different subnets etc etc). I proposed the use of a different variable so that we can override that behaviour, and at the same time allow the use of an existing subnet group or the creation of a new one with the modukle, preserving the functionality of the module itself as is. Thank you :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bryantbiggs WDYT? yes/no? :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is ok - maybe we could change var.cross_region_replica != true && ... to !var.cross_region_replica && ...

we could also update the replica examples to add an instance in another region to ensure this works (and continues to work as intended with any future changes)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm willing to do that for you if that is ok :)

@antonbabenko
Copy link
Member

¡Hola todos! Great to see so many approvals from Barcelona 🇪🇸 but let's hear if Bryant approves this, too :)

Copy link
Member

@antonbabenko antonbabenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

variables.tf Outdated Show resolved Hide resolved
variables.tf Outdated Show resolved Hide resolved
@antonbabenko antonbabenko changed the title fix to allow the creation of cross-region rds replicas feat: allow the creation of cross-region rds replicas Jul 7, 2021
@antonbabenko antonbabenko merged commit 90573a2 into terraform-aws-modules:master Jul 7, 2021
@antonbabenko
Copy link
Member

Vamos! :)

v3.3.0 has been just released.

@riccardo-salamanna
Copy link
Contributor Author

riccardo-salamanna commented Jul 7, 2021 via email

@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants