Open tmeijn opened 1 year ago
Instead of reverting pr 142, we should find a way to allow both null subnets for replicas and allow specifying subnets for replicas.
@Benbentwo could you look into this? Perhaps what we need is var.subnet_ids
for the primary and var.replica_subnet_ids
as an escape hatch for this use case which could default to null
.
@nitrocode If I understand the previous behavior correctly:
db_subnet_group_name = local.db_subnet_group_name_provided ? var.db_subnet_group_name : (
local.subnet_ids_provided ? join("", aws_db_subnet_group.default.*.name) : null
)
if local.subnet_ids_provided
is false, and no external db_subnet is provided, then it returns null
subnet_ids_provided = var.subnet_ids != null && length(var.subnet_ids) > 0
So not providing subnet_ids
to the module should evaluate to the same behavior PR #142 added, while also allowing the case that is described in this issue.
@nitrocode friendly reminder.
I unfortunately do not have the time at the moment but let me cc other folks in who may be able to review.
cc @aknysh @milldr
Describe the Bug
In version
0.38.7
you could specify different subnets for the replicas. This would result in a db subnet group being created specifically for the replica and assigned to it:In version
0.38.8
this is no longer possible due to the logic introduced in PR #142Now a replica configuration will always evaluate to
null
, which in my case causes the replica to take on the DB subnet group of the primary instance.Use case
Adobe Experience Platform Postgres Connector requires a publicly accessible database, so we have decided to create a replica in a public subnet, while the primary is in the private subnet. Version
0.38.7
allows this configuration and works, while version0.38.8
does not.Expected Behavior
I expect that when I specify subnets to the module, a DB subnet will be created and assigned to the replica.
Steps to Reproduce
Module configuration: