How to - Redeploy a VNet involved in a VNet integration with an Azure Function?

[rpothin]

Hello everyone 👋🏼,

Since few days I am working on an infrastructure as code deployment involving among other things a function app (Azure Functions) with a VNet integration.
I took my inspiration from the following example to configure the VNet integration: https://github.com/Azure/bicep/blob/main/docs/examples/101/function-premium-vnet-integration/main.bicep#L142

I have some code like below in a module for the deployment of the function app (with an app service plan):

resource functionAppNetworkConfiguration 'Microsoft.Web/sites/networkConfig@2021-01-01' = {
   parent: functionApp // Deployed in a previous step of the same module
   name: 'virtualNetwork'
   properties: {
      subnetResourceId: subnetId // Output from another module deployed in a previous step
      swiftSupported: true // I don't really know what this property is for 😅
   }
}

But if I try to deploy the same infrastructure as code without any change, I get the error below on the deployment of the VNet:

Subnet xxx is in use by /subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.Network/virtualNetworks/xxx/subnets/xxx/serviceAssociationLinks/AppServiceLink and cannot be deleted. In order to delete the subnet, delete all the resources within the subnet. See aka.ms/deletesubnet.

As a workaround I am currently removing the VNet integration in the function app if it exists before a deployment to be able to launch again the deployment without an error, but it is definitely not a perfect solution 😓

Am I doing something wrong here?

I naively thought that if you don't change anything in your code and deploy in incremental mode nothing should change in Azure, but it seems the deployment try to delete the subnet used for the VNet integration in the function app. But it is definitely not what I want to do here. I would like to be able to launch many deployments without any change in the code and without error 😁

Note: If you need more details do not hesitate to ask 😊

Thank you in advance for your help.

[brwilkinson]

Hi @rpothin are you able to share the code that you are using for the deployment of the VNET/Subnet?

Assuming that you are also including the "delegations" for "Microsoft.Web/serverfarms" on the redeployment of the subnet?

[rpothin]

Hey @alex-frankel,

I see 😓 I will make a test today to confirm this hypothesis.
As I like to "split" my code in small pieces I chose this strategy (VNet deployment then subnets deployment).

Do you think a control could be implemented in the deployment validation regarding this point?
It is always sad to think that your deployment will work and then see it fail in Azure 😅

[rpothin]

@alex-frankel, @brwilkinson,

After a test, I confirm that when I add the configuration of the subnets in the properties of the VNet (like presented here: https://github.com/Azure/bicep/blob/main/docs/spec/loops.md#generate-an-array-property-using-a-loop) I do not get the error about the VNet integration with the function app during the deployment of the VNet.

I think it could be great to have this in the validation of the deployment to get the error as soon as possible: deploy the subnets outside the VNet properties does not work if the subnet is involved in the VNet integration on a function app.

Thank you very much for your help.

[brwilkinson]

Thanks @alex-frankel for some reason I thought I had read (somewhere?) they made an update in the newer API's that allowed for deploying the VNET without overwriting the subnets property, however I guess that is not the case...

[rpothin]

@brwilkinson, @alex-frankel,

So is it something that will perhaps work in the future?
I mean: deploying a VNet, then a subnet involved in a VNet integration with a function app.

Thank you again very much for your help and have a great weekend 😊

[alex-frankel]

It is something that should eventually work in the future. We are working with the networking RP team to come up with a design for a redesigned API that can support child resources properly and eliminate this behavior. Don't have an ETA for this one unfortunately.