[AVM Module Issue]: avm/ptn/lz/sub-vending: Re-running fails trying to add another VNet peering

[cspring86]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Issue Type?

Bug

Module Name

avm/ptn/lz/sub-vending

(Optional) Module Version

0.1.5

Description

Following on from #3330

I updated to 0.1.5 and re-ran the pipeline.

The good news is that the subnet deletion problem looks to be fixed, thanks!

The bad news is that there's another issue.

It's trying to add another vnet peering even though one already exists because I'm running against an existing subscription.

Error:

{
  "code": "AnotherPeeringAlreadyReferencesRemoteVnet",
  "message": "Peering /subscriptions/***/resourceGroups/rg-alz-connectivity/providers/Microsoft.Network/virtualNetworks/alz-hub-eastus2/virtualNetworkPeerings/alz-hub-eastus2-alz-spoke-t2awudh7kzl5o-eastus2 already references remote virtual network Id: /subscriptions/xxx/resourceGroups/rg-alz-landingzones-online/providers/Microsoft.Network/virtualNetworks/alz-spoke-t2awudh7kzl5o-eastus2\r\nAddressSpace: \r\nResourceGuid: xxx\r\nProvisioningState: Succeeded\r\nCreatedTime: 0001-01-01T00:00:00.0000000\r\nLastModifiedTime: 0001-01-01T00:00:00.0000000\r\nPrefix, Subnet.Name\r\nNone\r\nSubnet details:\r\nIsSubnetIdAllocatedInNrp: False\r\nPrefix, Ipconfig.IsReferenceStub, Ipconfig.PrivateIPAddress, Ipconfig.Id\r\nNone\r\nCloudServices:\r\nGreKey: 0\r\nGreKeyAllocationId: 00000000-0000-0000-0000-000000000000\r\nGreKeyAllocationServiceUri: \r\nFailedGreKeyAllocationServiceUris:\r\nIDnsAclZoneId: \r\nRegionId: 0\r\nVnetFlowLogConfiguration: null\r\nExtendedLocation: . Cannot add another peering /subscriptions/***/resourceGroups/rg-alz-connectivity/providers/Microsoft.Network/virtualNetworks/alz-hub-eastus2/virtualNetworkPeerings/peer-alz-hub-eastus2-alz-spoke-t2awudh7kzl5o-eastus2 referencing the same remote virtual network.",
  "details": [],
}

Let me know if you need any more details.

(Optional) Correlation Id

No response

[avm-team-linter]

@cspring86, thanks for submitting this issue for the avm/ptn/lz/sub-vending module!

Important

A member of the @Azure/avm-ptn-lz-subvending-module-owners-bicep or @Azure/avm-ptn-lz-subvending-module-contributors-bicep team will review it soon!

[sebassem]

We will try to repro and revert back asap

[jtracey93]

Hey @cspring86,

Thanks for the issue and thanks @sebassem for investigating.

I think the issue here is more a conflict style error, in that a peering has been created outside of this module declaration and now the module is trying to create a peering as the input parameter has been specified to create one and the name of the Microsoft.Network/virtualNetworks/virtualNetworkPeerings resource does not match the name of the existing peering which is causing it to error here.

Is that correct @cspring86, that this peering was initially created outside of this sub vending module call, and now you have added it by supplying inputs to virtualNetworkPeeringEnabled = true and hubVirtualNetworkResourceIdChecked = <hub VNET Resource ID>?

If so, then the fix would be to:

1. Expose the peerings.name property as an optional input to the sub vending module for the peering - https://github.com/Azure/bicep-registry-modules/blob/main/avm/res/network/virtual-network/main.bicep#L371 and adding it to this call of the AVM Resource Module for VNET https://github.com/Azure/bicep-registry-modules/blob/main/avm/ptn/lz/sub-vending/modules/subResourceWrapper.bicep#L379-L390

This will then allow this module to work in more "brownfield" style deployments as they can specify the peering name to avoid this conflict style error.

[cspring86]

Is that correct @cspring86, that this peering was initially created outside of this sub vending module call

Hi @jtracey93

No, it was created through the sub vending module.

The peering name is the same in Azure as the module is trying to create when running again.

Hope this helps!

[hectorm-bmg]

I'm seeing the same issue. I used the sub-vending module to create a new subscription with a peering to the hub network.
Then if I delete the new subscription and also delete the peering in the hub network I get this error:
New-AzManagementGroupDeployment:
Line |
9 | New-AzManagementGroupDeployment @InputObject
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| An error occurred while sending the request.

[sebassem]

Is that correct @cspring86, that this peering was initially created outside of this sub vending module call

Hi @jtracey93

No, it was created through the sub vending module.

The peering name is the same in Azure as the module is trying to create when running again.

Hope this helps!

@cspring86 @jtracey93 I think there is a bug in the latest VirtualNetwork AVM module. This might be related

[jtracey93]

@cspring86 & @hectorm-bmg are you getting the error of Resource is in Updating state and the last operation that updated/is updating the resource is PutSubnetOperation. if you check nested deployments?

Just to confirm what @sebassem sees?

As i see we may have slightly different errors and want to ensure we triple check 👍

[cspring86]

@jtracey93 I get an error in the lz-vend-vnet-create-vlug37hl3vkds deployment.

Both the local and remote vnet peering deployments fail:

The error messages are:

Peering /subscriptions/xxx/resourceGroups/rg-alz-connectivity/providers/Microsoft.Network/virtualNetworks/alz-hub-eastus2/virtualNetworkPeerings/alz-hub-eastus2-alz-spoke-t2awudh7kzl5o-eastus2 already references remote virtual network Id: /subscriptions/yyy/resourceGroups/rg-alz-landingzones-online/providers/Microsoft.Network/virtualNetworks/alz-spoke-t2awudh7kzl5o-eastus2

Peering /subscriptions/yyy/resourceGroups/rg-alz-landingzones-online/providers/Microsoft.Network/virtualNetworks/alz-spoke-t2awudh7kzl5o-eastus2/virtualNetworkPeerings/alz-spoke-t2awudh7kzl5o-eastus2-alz-hub-eastus2 already references remote virtual network Id: /subscriptions/xxx/resourceGroups/rg-alz-connectivity/providers/Microsoft.Network/virtualNetworks/alz-hub-eastus2

[hectorm-bmg]

I tried running the sub-vending module again today ( without deleting the peering on the hub network ). I did not get the error this time.

[sebassem]

@cspring86 Can you try another deployment after bumping the patch version. The problem with the virtual network module should have been fixed