[AVM Question/Feedback]: Ignore changes to some parameters

[Cyr-Az]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Description

Hi,

We're facing a scenario where the network team is responsible for network-related terraform code and same goes for system team and system-related code, each with dedicated projects and tfstates. Network team uses the avm vnet module to deploy vnets, peerings etc.
System resources (including DNS VMs) are deployed afterwards, and these VMs IPs are configured as the vnet's dns servers using azurerm_virtual_network_dns_servers.
The issue is that when Network team does some modifications to its code, the DNS servers are removed from the configuration.

There are/were similar issues in the Keyvault or container registry modules, (ie. Azure/terraform-azurerm-avm-res-containerregistry-registry@0a74706 ) , but not too sure how this could be implemented in the vnet module since it's based on azapi instead of azurerm provider.

Any idea how we could solve that situation?

Thanks !

[jaredfholgate]

Hi. Just to confirm, are you saying that every VNET you deploy has its own DNS VMs deployed inside it and then has its own DNS updated to point to the VMs inside that VNET?

If that is the case, then there are a few options:

1 - Reserve the static ip addresses of the DNS servers and the network team sets them up front.

2 - The network team re-run their pipeline once the DNS ip addresses are known.

3 - If 1 or 2 are not possible, we may need to make an update to the module to handle this edge case.

[Cyr-Az]

Hi @jaredfholgate and sorry for the confusion, I was trying to simplify my explanation but as often in that case it resulted in less clarity.
The actual scenario is that the system team deploys AD domain controllers in the "Identity" subscription and then their IP addresses need to be used as DNS servers in every subsequent "platform" and "corp landing zone" peered vnet.

1. not fan of reserving the IPs as we're trying to maintain the code as modular and dynamic as possible, but that would of course be an option
2. also not fan of that solution as we would like to prefer to maintain the projects as independed from each other as possible. However I was thinking of a (nasty) workaround were the "Identity" project would publish the domain controllers as gitlab CI variables and the "Network" project would use that variable as an input. If variable empty or not set yet, the vnets are created without dns servers as expected; once the variable is set the vnets are known to the "Netowrk" project and so it won't try to remove them.
3. of course that would be the best solution for me, but I would totally understand if it's not a priorty :)

[jaredfholgate]

I’m afraid I am still a bit confused. If you are using our standard Azure Platform Landing Zone pattern, I am unsure why you would not know the ip address of the DNS servers when vending subscriptions and creating / peering the vnets?

I appreciate you have siloed teams, but given the ip address of those AD domain controllers will never change, why can’t the DNS servers be set when the VNET is created?

Or are you saying that you are creating new domain controllers in the identity sub for each workload?

[Cyr-Az]

Once again you're correct, I got a bit carried away in my explanation; only the subsequents vnets in identity and management subscriptions are an issue here

[jaredfholgate]

I've added the long term label as would like to take a look at supporting updates to DNS zones independently.