Currently, we have bicep templates that deploy an Azure Firewall, and over time, we add additional IP configurations to the firewall. Upon redeployment of the bicep, the additional IP configs are removed. This is because ARM is treating them as a property rather than a child resource.
Is there any way to treat the IP configs as a child resource so this does not happen? Each IP configuration has its own resource ID. I view this as similar to a VNet and Subnet (which supports both child resources and properties).
Our current solution is to do a lookup on the IP Configurations and then pass them as parameters to the bicep, but this is susceptible to race conditions if an IP is successfully added/updated/deleted between the lookup and the bicep deployment. Perhaps we could pass ETags from the lookup to Bicep and that could someway help mitigate the race condition? Not sure.
At a high level though, the issue is that subsequent deployments of a firewall cause the intermittently added public IPs to disappear.
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @fwsuppgithub. Please see https://aka.ms/biceptypesinfo for troubleshooting help.
Currently, we have bicep templates that deploy an Azure Firewall, and over time, we add additional IP configurations to the firewall. Upon redeployment of the bicep, the additional IP configs are removed. This is because ARM is treating them as a property rather than a child resource.
Is there any way to treat the IP configs as a child resource so this does not happen? Each IP configuration has its own resource ID. I view this as similar to a VNet and Subnet (which supports both child resources and properties).
Our current solution is to do a lookup on the IP Configurations and then pass them as parameters to the bicep, but this is susceptible to race conditions if an IP is successfully added/updated/deleted between the lookup and the bicep deployment. Perhaps we could pass ETags from the lookup to Bicep and that could someway help mitigate the race condition? Not sure.
At a high level though, the issue is that subsequent deployments of a firewall cause the intermittently added public IPs to disappear.