You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This module has features leaving to think it's able to deploy private and public subnets separately. It mostly works but, apparently, you must have both public and private enabled to get the NAT Gateways created, leaving the user to deal with it separately even if the resources to create them are already existing into the module.
This is due to: local.nat_gateway_enabled is true if nat_gateway_enabled = local.nat_gateway_useful && local.nat_gateway_setting
local.nat_gateway_useful is true if nat_gateway_useful = local.nat_instance_useful || local.public_dns64_enabled || local.private_dns64_enabled
About nat_gateway_setting, if nat_instance_enabled is set to true, we set the default for nat_gateway_enabled to false. This is the only place across the module where the var nat_gateway_enabled is actually used.
then local.nat_instance_useful is true if nat_instance_useful = local.private4_enabled
and local.private4_enabled is true if private4_enabled = local.private_enabled && local.ipv4_enabled
Is there a reason I'm overlooking linking the NATGW creation to the private subnets (beside the need of private to use it, but we would create them separately).
Would my change breaking or go against any internal logic you are aware of? My first choice would be to set nat_instance_useful = local.public4_enabled because that's what the NATGW requires, but, to be backward compatible, even nat_instance_useful = local.private4_enabled || local.public4_enabled would be OK, at least we could deploy (and I would be happy to share a working an example on how to do it) different number of private/public at will.
Expected Behavior
If the variable nat_gateway_enabled is set to true with private_subnets_enabled set to false, I would expect the NAT gateways to be created, leaving the user able to use that instead of creating it separately.
Describe the Bug
This module has features leaving to think it's able to deploy private and public subnets separately. It mostly works but, apparently, you must have both public and private enabled to get the NAT Gateways created, leaving the user to deal with it separately even if the resources to create them are already existing into the module.
This is due to:
local.nat_gateway_enabled
is true ifnat_gateway_enabled = local.nat_gateway_useful && local.nat_gateway_setting
local.nat_gateway_useful
is true ifnat_gateway_useful = local.nat_instance_useful || local.public_dns64_enabled || local.private_dns64_enabled
About
nat_gateway_setting
, ifnat_instance_enabled
is set to true, we set the default fornat_gateway_enabled
tofalse
. This is the only place across the module where the varnat_gateway_enabled
is actually used.then
local.nat_instance_useful
is true ifnat_instance_useful = local.private4_enabled
and
local.private4_enabled
is true ifprivate4_enabled = local.private_enabled && local.ipv4_enabled
finally
private_enabled = local.e && var.private_subnets_enabled
So, the NATGW won't be created if the
private_subnets_enabled
variable is set to false.The change is obviosly trivial, I would just set
or, in all honesty even
My question is:
nat_instance_useful = local.public4_enabled
because that's what the NATGW requires, but, to be backward compatible, evennat_instance_useful = local.private4_enabled || local.public4_enabled
would be OK, at least we could deploy (and I would be happy to share a working an example on how to do it) different number of private/public at will.Expected Behavior
If the variable
nat_gateway_enabled
is set totrue
withprivate_subnets_enabled
set to false, I would expect the NAT gateways to be created, leaving the user able to use that instead of creating it separately.Steps to Reproduce
Just try to deploy the module with
No NAT gateways will be created
Screenshots
No response
Environment
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: