Open Gossef opened 1 week ago
I am not entirely sure who to assign this issue two, so I did the next best thing and involved the two owners we have for the Virtual WAN, Virtual Hub & Azure Firewall modules. @hundredacres & @arnoldna, would you happen to have any advise here?
I've disabled the additional routing tables and then the resources deploy. However the default route table is now empty:
This comes from this part of the code in the Virtual Hub main.bicep:
module virtualHub_routingIntent 'hub-routing-intent/main.bicep' = if (!empty(**azureFirewallResourceId**) && (internetToFirewall || privateToFirewall)) {
name: '${uniqueString(deployment().name, location)}-routingIntent'
params: {
virtualHubName: virtualHub.name
azureFirewallResourceId: azureFirewallResourceId
internetToFirewall: internetToFirewall
privateToFirewall: privateToFirewall
}
}
The problem lies in the azureFirewallResourceId here, which needs to be empty to prevent the cyclical dependency (as the Azure Firewall resource creation depends on the Virtual Hub creation).
It's also listed in the description field of the routing intent bicep file: "This module configures Routing Intent for a Virtual Hub; this module requires an existing Virtual Hub, as well the firewall Resource ID"
Check for previous/existing GitHub issues
Description
We're trying to convert our VWAN setup from older Bicep resources to AVM modules and we're running into some cyclical dependency issues.
Our VWAN setup consists of:
the VWAN module: br/public:avm/res/network/virtual-wan:0.3.0 2 Virtual Hub modules (nonp + prd): br/public:avm/res/network/virtual-hub:0.2.2 2 Azure Firewall modules (nonp + prd): br/public:avm/res/network/azure-firewall:0.5.0
The Azure Firewall modules have a hard dependency on the Virtual Hub modules due to the virtualHubId parameter.
For the hubRouteTables parameter of the Virtual Hub each object needs the Firewall for the "nextHop" in our setup, but that's not possible since the Firewall has a dependency on the Hub. So basically a cyclical dependency. We have extended the defaultRouteTable with an additional entry (the other two are already covered by default values of Routing Intent) I'm currently trying to create the route tables independently, but it feels wrong to have to break things out of the AVM module to circumvent these issues. However, the hubVirtualNetworkConnections routingConfiguration refers to the defaultRouteTable, which is then also not created yet.
Is there any other way of getting this done?