potential bug: vnet resource and peerings

[nyanhp]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Versions

Please paste the output of terraform version command from within the initialized directory:

Terraform v1.7.4
on windows_amd64

Please enter the module version that you are using:

4.0.2
Tested AzApi 1.11.0 - 1.12.1

Description

A first deployment works, every plan thereafter runs into the error:

Error: embedded schema validation failed: the `body` is invalid:
│ `properties.virtualNetworkPeerings.0.properties.routeServiceVips` is not expected here. Do you mean `properties.virtualNetworkPeerings.0.properties.resourceGuid`?
│ `properties.virtualNetworkPeerings.0.properties.resourceGuid` is not expected here, it's read only
│ `properties.virtualNetworkPeerings.0.properties.provisioningState` is not expected here, it's read only
│ `properties.virtualNetworkPeerings.0.properties.peerCompleteVnets` is not expected here. Do you mean `properties.virtualNetworkPeerings.0.properties.peeringState`?
│ `properties.virtualNetworkPeerings.0.etag` is not expected here, it's read only
│  You can try to update `azapi` provider to the latest version or disable the validation using the feature flag `schema_validation_enabled = false` within the resource block

I'm a bit flummoxed as the deployment worked fine in the past - I simply don't know what changed.

Steps to Reproduce

Normal LZ deployment. I cannot reasonably redact all the client information, it's a big deployment. The vnet in question is configured as:

"vn1": {
          "name": "vnet-redacted",
          "hub_peering_use_remote_gateways": false,
          "resource_group_name": "rg-redacted",
          "address_space": [
            "192.168.1.0/24"
          ],
          "hub_network_resource_id": "/subscriptions/redacted/resourceGroups/redacted-connectivity-westeurope-networking/providers/Microsoft.Network/virtualNetworks/redacted-hub-westeurope-networking",
          "hub_peering_name_fromhub": "redacted-hub-westeurope-networking-to-redacted",
          "hub_peering_enabled": true,
          "hub_peering_name_tohub": "redacted-to-redacted-hub-westeurope-networking"
        }

1. terraform plan, no peerings in place yet
2. terraform apply, peerings are configured
3. terraform plan -> The error occurs

Screenshots

Additional context

[matt-FFFFFF]

Hi is this still happening?

[richardbeumer]

Any solution for this issue? Facing the same problem here.

[NathanAWhitworth]

We're running into this same issue, but with VWAN hubs:

│ embedded schema validation failed: the argument "body" is invalid:
│ `properties.virtualNetworkPeerings.0.etag` is not expected here, it's read only
│ `properties.virtualNetworkPeerings.0.properties.provisioningState` is not expected here, it's read only
│ `properties.virtualNetworkPeerings.0.properties.routeServiceVips` is not expected here. Do you mean `properties.virtualNetworkPeerings.0.properties.resourceGuid`?
│ `properties.virtualNetworkPeerings.0.properties.resourceGuid` is not expected here, it's read only
│ `properties.virtualNetworkPeerings.0.properties.peerCompleteVnets` is not expected here. Do you mean `properties.virtualNetworkPeerings.0.properties.peeringState`?
│ `properties.virtualNetworkPeerings.0.properties.remoteGateways` is not expected here. Do you mean `properties.virtualNetworkPeerings.0.properties.useRemoteGateways`?
│ `properties.subnets.0.etag` is not expected here, it's read only
│ `properties.subnets.0.properties.provisioningState` is not expected here, it's read only
│  You can try to update `azapi` provider to the latest version or disable the validation using the feature flag `schema_validation_enabled = false` within the resource block

Module: 4.1.4
Terraform: 1.9.5
azapi: 1.15.0

Disabling schema validation on the VNet resource in a local copy of the module resolves the issue, and it seems like there might be something odd going on with schemas in the state file.

The affected instance has this in the state file:

"body": {
  "value": {
    "properties": {
      "addressSpace": {
        "addressPrefixes": [
          "10.2.16.0/25"
        ]
      },
      "dhcpOptions": {
        "dnsServers": [
          "10.2.2.4",
          "10.1.2.4",
          "10.0.2.4",
          "10.3.2.4"
        ]
      },
      "enableDdosProtection": false,
      "subnets": [],
      "virtualNetworkPeerings": []
    }
  },
  "type": [
    "object",
    {
      "properties": [
        "object",
        {
          "addressSpace": [
            "object",
            {
              "addressPrefixes": [
                "tuple",
                [
                  "string"
                ]
              ]
            }
          ],
          "dhcpOptions": [
            "object",
            {
              "dnsServers": [
                "tuple",
                [
                  "string",
                  "string",
                  "string",
                  "string"
                ]
              ]
            }
          ],
          "enableDdosProtection": "bool",
          "subnets": [
            "tuple",
            []
          ],
          "virtualNetworkPeerings": [
            "tuple",
            []
          ]
        }
      ]
    }
  ]
}

whereas a seemingly unaffected instance with otherwise identical config has this:

"body": {
  "value": "{\"properties\":{\"addressSpace\":{\"addressPrefixes\":[\"10.1.16.0/25\"]},\"dhcpOptions\":{\"dnsServers\":[\"10.1.2.4\",\"10.0.2.4\",\"10.3.2.4\",\"10.2.2.4\"]}}}",
  "type": "string"
}

I can't see any obvious differences between these resources outside of the terraform state.

[NathanAWhitworth]

Same issue in #429