Subnets still created when configuration scope set to enabled = false

[ATuckwell]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Versions

terraform: 1.1.2

azure provider: 3.0.2

module: 2.3.1

Description

Describe the bug

During a recent customer deployment there was some confusion created when the VNG and AF config was set to enabled = false, but the module still attempted to deploy these subnets, i.e. The CIDR ranges that were left within the VNG and AF address prefix still showed up within a terraform plan. Only when the address prefix was removed did the module stop trying to create these subnets.

Steps to Reproduce

Within the advanced configuration of a Virtual network using the settings.connectivity.tf (as per guide here), the hub network is configured with the required address space.

Example hub network config

If virtual network gateway or azure firewall config is set to enabled = false, but has address prefix configured, the module will try to create this subnet within the hub virtual network.

If the address prefix is a valid address range within the virtual network address space the subnet will be created, even though enabled = false. This has been confirmed for both the VNG and AF subnets.

If the Address prefix is NOT a valid address range within the virtual network address space, then it will show on the terraform plan, but will error upon terraform apply (as expected as this is not a valid prefix).

Screenshots

Screenshots added above.

Additional context

• This may not be a bug, and is potentially expected behaviour, but this issue caused issues during a customer deployment using the advanced deployment guidance.
• This has only been tested within the first hub network, but assumption is that the second hub network will use the same logic.

[krowlandson]

Thank you for logging this @ATuckwell... as discussed online, this should be a relatively simple fix and the outcome you describe was the original intent of the logic.

I also don't feel this should have a negative impact on existing customers once implemented so we should be able to add this under a minor release.

Will speak to the team to get this appropriately prioritised on our backlog.

[ATuckwell]

@JamJarchitect , FYI as per proposal of updating logic within module.

[krowlandson]

Trigger ADO Sync