ms-henglu
commented
6 months ago Hi @HaruY96 ,
Thank you for taking time to report this issue.
The below trace seems from a response, because it has etag and type set. And I've confirmed that virtualNetworkPeerings property is managed by a separate resource: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/virtual_network_peering
{
"name": "sample-name-VNet-2",
"id": "/subscriptions/xx/resourceGroups/xx/providers/Microsoft.Network/virtualNetworks/sample-name-VNet-2",
"etag": "xx"",
"type": "Microsoft.Network/virtualNetworks",
"location": "australiaeast",
"tags": {
...
},
"properties": {
"provisioningState": "Updating",
"resourceGuid": "xx",
"addressSpace": {
"addressPrefixes": ["10.xx.xx.xx/26"]
},
"dhcpOptions": {
"dnsServers": ["10.xx.xx.5"]
},
"subnets": [],
"virtualNetworkPeerings": [],
"enableDdosProtection": false
}
}
Is there an existing issue for this?
Community Note
Terraform Version
1.4.6
AzureRM Provider Version
3.68.0
Affected Resource(s)/Data Source(s)
virtual network
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
There is nothing changed for the Terraform deployment code and nothing change for the Azure Policy definition.
Before last Monday (5/27), virtual network resources deployed by Terraform worked fine. But since 5/27, the same Terraform deployment failed due to a deny policy which is checking the virtualNetworkPeerings property.
For the failed deployment on 5/27, the following request payload can be checked from TF debug log.
{ "location": "australiaeast", "properties": { "addressSpace": { "addressPrefixes": ["10.xx.xx.0/23"] }, "dhcpOptions": { "dnsServers": ["10.xx.xx.132"] }, "subnets": [{ "id": "/subscriptions/xx/resourceGroups/xx/providers/Microsoft.Network/virtualNetworks/sample-name-VNet1/subnets/sample-name-subnet1", "name": "sample-name-subnet1", "properties": { "addressPrefix": "10.210.250.0/23", "delegations": [], "networkSecurityGroup": { "id": "/subscriptions/xx/resourceGroups/xx/providers/Microsoft.Network/networkSecurityGroups/sample-name-NSG1" }, "privateEndpointNetworkPolicies": "Enabled", "privateLinkServiceNetworkPolicies": "Enabled", "routeTable": { "id": "/subscriptions/xx/resourceGroups/xx/providers/Microsoft.Network/routeTables/sample-name-RT1" }, "serviceEndpoints": [] }, "type": "Microsoft.Network/virtualNetworks/subnets" } ] }, "tags": { ..... } }
For the succeed deployment on 5/14, the following request payload can be checked from Azure Networking resource provider side. (We are working with Azure Networking engineer.)
{ "name": "sample-name-VNet-2", "id": "/subscriptions/xx/resourceGroups/xx/providers/Microsoft.Network/virtualNetworks/sample-name-VNet-2", "etag": "xx"", "type": "Microsoft.Network/virtualNetworks", "location": "australiaeast", "tags": { ... }, "properties": { "provisioningState": "Updating", "resourceGuid": "xx", "addressSpace": { "addressPrefixes": ["10.xx.xx.xx/26"] }, "dhcpOptions": { "dnsServers": ["10.xx.xx.5"] }, "subnets": [], "virtualNetworkPeerings": [], "enableDdosProtection": false } }
The deployment process should be TF->ARM->NRP. ARM will not add/remove property. Obviously, we can see the "virtualNetworkPeerings" property was removed in the failed deployment.
Actual Behaviour
VNet resource deployment failed due to deny policy blocked. The deny policy was triggered due to the missing virtualNetworkPeerings property was removed from request payload.
Steps to Reproduce
No response
Important Factoids
No response
References
No response