Bicep Incremental deployments not working as expected

[Fatwes]

Hello all, I am truly grateful for all the MLZ work.

After I deploy the MLZ, and then update the main BICEP with an additional resource and try to redeploy, it fails. The deployment tries to delete subnets. Specifically I am seeing:

"InUseSubnetCannotBeDeleted: In order to delete the subnet, delete all the resources within the subnet"

When I add a resource to the main BICEP, it should add the resource and not delete anything. This is how incremental default bicep should work correct? My use case is simply adding onto my existing environment. Any help here would be appreciated.

I am deploying at the subscription level as well.

[brooke-hamilton]

Which type of resource are you adding? I would like to try the same scenario. Thank you for the question!

[Fatwes]

Hi brooke, thanks for the quick response. I added another module to create a basic CosmosDB and only called that. Based on my understanding nothing should be destroyed, it should just add onto the existing resources correct? I posted this question in the Azure/bicep repo by accident and they said :

"It sounds like the VNET is created First with blank subnets. Then the subnets are being created.

Then on the next deploy the VNET is trying to delete the subnets."

could that be the issue?

[Fatwes]

@brooke-hamilton did you get a chance to try this? I havent been able to figure out why it wants to delete subnets when the only update to the main.bicep is calling a module to create a new resource

[brooke-hamilton]

@Fatwes thank you for this question. Based on this question, I created issue #695 to track why redeployments fail and determine if we can do anything to make it better in the short-term. When someone deploys MLZ and then executes the same deployment again, the second deployment fails when trying to delete/recreate the hub subnet. As you pointed out, nothing related to the subnet is really changing so ideally we should be able to re-deploy without any resources being destroyed and recreated.

Until we sort that out I think the best workaround is to treat your additional deployments of new resources within MLZ as separate deployments. We already do that for Tier 3 workloads, i.e., deploying a new workload tier is a separate deployment from the base MLZ deployment.

Another consideration is that our roadmap has work defined for making MLZ deployments more modular. That should help the issues with idempotency (destroy/create rather than update). Please take a look at the "Future Focus Area" section for how we would like to support NoOps/GitOps. Such a system would allow small changes to configuration in code that trigger small changes in the deployed infrastructure. #658 is related.