Bug: Creating additional Subnets for NVA's does not work as expected

[richardf5]

Is there an existing issue for this?

• I have searched the existing issues

Infrastructure as Code Type? (Required)

terraform

PowerShell Module Version (Optional)

4.3

Bootstrap Module Version (Optional)

5.0.0

Starter Module? (Required)

terraform - platform_landing_zone

Starter Module Version (Optional)

9.0.1

Input arguments of the ALZ-PowerShell-Module (Optional)

No response

Debug Output/Panic Output (Optional)

Expected Behaviour (Required)

Adding additional subnets to "hub_and_spoke_vnet_virtual_networks \ primary \ hub_virtual_network \ subnets" should allow me to create additional subnets.

Actual Behaviour (Required)

The second subnet in the list is the only one that gets created!

Steps to Reproduce (Optional)

In custom_replacements \ names:

1. Remove the single Primary NVA variable
2. Add the new variables:

• primary_mgmt_subnet_nva_name = "snet-nva-mgmt-primary-connectivity"
• secondary_mgmt_subnet_nva_name = "snet-nva-mgmt-secondary-connectivity"
• untrusted_subnet_nva_name = "snet-nva-external-connectivity"
• trusted_subnet_nva_name = "snet-nva-internal-connectivity"
• semitrusted_subnet_nva_name = "snet-nva-dmz-connectivity"

3. Add new address range variables:

• Primary_mgmt_nva_subnet_address_prefix = "10.4.0.0/28"
• secondary_mgmt_nva_subnet_address_prefix = "10.4.0.16/28"
• untrusted_nva_subnet_address_prefix = "10.4.0.32/28"
• trusted_nva_subnet_address_prefix = "10.4.0.48/28"
  Under hub_and_spoke _virtual_networks \ primary \ hub_virtual_network \ subnets:

1. Remove the NVA Subnet definition.

2. Add the new definitions based on the variables above:

   subnets = {
   primary_mgmt_nva = {
   name = "$${primary_mgmt_subnet_nva_name}"
   address_prefixes = ["$${primary_mgmt_nva_subnet_address_prefix}"]
   }
   secondary_mgmt_nva = {
   name = "$${secondary_mgmt_subnet_nva_name}"
   address_prefixes = ["$${secondary_mgmt_nva_subnet_address_prefix}"]
   }
   untrusted_nva = {
   name = "$${untrusted_subnet_nva_name}"
   address_prefixes = ["$${untrusted_nva_subnet_address_prefix}"]
   }
   trusted_nva = {
   name = "$${trusted_subnet_nva_name}"
   address_prefixes = ["$${trusted_nva_subnet_address_prefix}"]
   }
   semitrusted_nva = {
   name = "$${semitrusted_subnet_nva_name}"
   address_prefixes = ["$${semitrusted_nva_subnet_address_prefix}"]
   }
   }

Important Factoids (Optional)

I have replaced the nva subnet definition with the five subnets that this 3rd-party firewall requires:

• Trusted (aka Internal)
• Untrusted (aka Internet)
• SemiTrusted (aka DMZ)
• Management Primary
• Management Secondary

References (Optional)

No response

[jaredfholgate]

Thanks for reporting. This is odd, I can't see anything obvious in the code that would cause this, so need to reproduce.

[richardf5]

Thanks. The other weird thing was that I corrected a typo in the Subnets section (I misspelt one of the new variables).
Terraform wanted to destroy the majority of the network resources including the VNET, Private DNS Zones etc. As you can imagine, I can't expect customers to take that level of risk on once we've deployed the accelerator for them as part of an engagement.

I'm guessing I should log that as a separate issue/bug?

[jaredfholgate]

Thanks. The other weird thing was that I corrected a typo in the Subnets section (I misspelt one of the new variables). Terraform wanted to destroy the majority of the network resources including the VNET, Private DNS Zones etc. As you can imagine, I can't expect customers to take that level of risk on once we've deployed the accelerator for them as part of an engagement.

I'm guessing I should log that as a separate issue/bug?

Yes please. It could be related to a data source we are using that I plan to take a look at, but would be useful to see the output of your plan to validate that. Having an issue to track it will be helpful.