Bug Report

[berky-ms]

Describe the bug Hi,

A customer asked us to do an ALZ deployment with a single subscription model with workload subscription having multiple VNETs. (i.e.; single Hub subscription with single VNET, single workload subscription with multiple VNETs). That's not in accordance with normal Hub-Spoke setup where each workload subscription has only one Spoke VNET, but that was what they asked for. On the ALZ user interface we checked if it was possible to assign multiple VNETs to a single workload subscription and saw that it was possible. So we went for it. However, the deployment failed as the deployment name of the nested template (which deploys the VNETs and relevant peering to Hub) is same for all of them. Because the deployment name is same, it is not possible to deploy that nested template at the same time. The error says, there is already an active deployment going on with that name. At very below you can see the full error we got as well as the ARM template we retrieved from deployment logs.

When we checked the nested template, we also saw that the name of the VNETs in the ARM templates are also same, which means it wouldn't actually deploy the next VNETs even this deployment name error was fixed as VNET names in the nested templates are also same. But not sure of this totally, we checked it over the source nested template in repo.

Actually it might be that ALZ scripts do not support this custom type deployment (single workload subscription with multiple VNETs) but the prevention on the user interface is forgotten. If it is not allowed in the User Interface, we can tell the customers this is not supported from the beginning.

Full Error {"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.","details":[{"code":"Conflict","message":"{\r\n \"error\": {\r\n \"code\": \"DeploymentActive\",\r\n \"message\": \"Unable to edit or replace deployment 'alz-vnet-uksouth-sywupa': previous deployment from '6/26/2024 1:11:43 PM' is still active (expiration time is '7/3/2024 1:11:43 PM'). Please see https://aka.ms/arm-deploy-resources for usage details.\"\r\n }\r\n}"}]}

ARM template `{ "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": {}, "variables": {}, "resources": [ { "type": "Microsoft.Network/virtualNetworks", "apiVersion": "2020-06-01", "name": "", "location": "uksouth", "dependsOn": [], "properties": { "addressSpace": { "addressPrefixes": [ "" ] }, "dhcpOptions": { "dnsServers": [ "" ] } } }, { "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings", "apiVersion": "2020-05-01", "name": "/peerToHub", "dependsOn": [ "" ], "properties": { "remoteVirtualNetwork": { "id": "" }, "allowVirtualNetworkAccess": true, "allowForwardedTraffic": true, "allowGatewayTransit": true, "useRemoteGateways": false } }, { "type": "Microsoft.Resources/deployments", "apiVersion": "2020-06-01", "name": "", "dependsOn": [ "" ], "properties": { "mode": "Incremental", "expressionEvaluationOptions": { "scope": "inner" }, "parameters": { "remoteVirtualNetwork": { "value": "" }, "hubName": { "value": "" } }, "template": { "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "remoteVirtualNetwork": { "type": "String", "defaultValue": false }, "hubName": { "type": "String", "defaultValue": false } }, "variables": {}, "resources": [ { "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings", "name": "[concat(parameters('hubName'),'/',last(split(parameters('remoteVirtualNetwork'),'/')))]", "apiVersion": "2020-05-01", "properties": { "allowVirtualNetworkAccess": true, "allowForwardedTraffic": true, "allowGatewayTransit": true, "useRemoteGateways": false, "remoteVirtualNetwork": { "id": "[parameters('remoteVirtualNetwork')]" } } } ], "outputs": {} } }, "subscriptionId": "", "resourceGroup": "" } ], "outputs": {} }

`

[jtracey93]

Hey @berky-ms, this is fine from an architecture perspective, you may want to review the very new guidance we published on this here: https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/subscription-vending-product-lines

However our ALZ portal accelerator does not support this today, so you can do this after you've ran the ALZ portal experience by manually creating the additional VNETs you want in the application/workload subscription.

[berky-ms]

Hi Jack,

I had a talk with the product team and as I told them I already I handled it manually after the fail.

As i wrote in the report above, the scripts do not seem to support multiple Vnets even though the deployment name issue would be fixed (since the name of the Vnets in the nested template would be same for further Vnet deployments).

I also told the team, ours was not a conventional ALZ deployment as we know of (also wrote in the above report), where every workload subscription has a single spoke vnet.

I was told by the team that adding multiple Vnets to a single workload subscription was not the intended use of the user interface section (the section where you choose the workload subscription and the CIDR for the Spoke Vnet). I think just disabling this (disabling of same Subscription choice again in that section) would suffice to prevent such unintended use.

[Springstone]

Closing the issue, as there is no action required from ALZ team.