Support VNET re-deployment without destroying subnets
When you deploy a VNET from an ARM template in incremental mode I would expect omitting the subnet property would not change the subnets since they are child resources. Instead they are destroyed. I think this is inconsistent with all other similar resource types e.g. app service plans and web apps, azure SQL servers and databases, etc... Please make VNETs and subnets deployments consistent.
Thanks for this suggestion. Apologies for the inconvenience this inconsistent behavior has caused, while we look into it, note a workaround that has worked for a few:
- Anavi N [MSFT]
@Admin @Anavi N [MSFT] Can you please send us an update on this issue? We keep running into making complex deploymenta to meet our goals
The solution pointed to by Admin does not work if you need to change the properties of a VNET, e.g. the DNS settings, after you have deployed a subnet and virtual machines. The answer would be to remove subnets as a property and allow the management of them as separate resources (which is already possible). Yes this would be a breaking change but it would remove a massive area of pain for people trying to manage their environment via ARM templates.
My situation doesn't lend itself well to the solution mentioned in the Jul 31 response from ADMIN (see my other comments on the github issue). Managing it outside of a template is easier at this point, but it wouldn't be easier if I could deploy a VNET and it's properties without having to specify all subnets.
Subnets can be deployed individually, but not a VNET. Is there a good reason it is not like other resources with parent/child relationships (app service plans and web apps, azure SQL servers and databases, etc...)?
Yes. Please fix this.
David Connor commented
@pkhabazi, your solution may work, but it tightly couples the definition of subnets to the same template file as the VNet, which is not what I was trying to achieve... I can't believe this issue has been open for so long! Get it fixed Microsoft.
I think its more related of the way you deploy a VNet, I have written a blog regarding this issue a while ago and explained how you can keep redeploying your VNet without destroying your subnets: https://pkm-technology.com/azure-vnet-json/
Andrew McGregor commented
We simply cannot update the state of the deployment with this limitation. It is defeating the idea of infrastructure as code as we need to use the portal to do so..
Connor Dickson commented
The ability to conditionally deploy a subnet or to add a VNet at a later stage is a requirement. If I can add them individually through the portal it should be possible through ARM templates.
Jonathan Eckman commented
This is a big limitation for us. After our VNET is used, we are no longer able to deploy changes to it because it is attempting to delete our subnets which are created in a separate deployment.
Perhaps a solution could be to make subnets resources rather than a property of a the virtual network resource. This way incremental deployments of the template would not remove the existing subnet's if they are not defined in the template.