vnet peering create --allow-vnet-access help text wrong?

[mhyllander]

Describe the bug
It seems to me that the help text for the --allow-vnet-access option of the "az network vnet peering create" command is wrong. I think the effect is the opposite.

To Reproduce
Create two vnets in a resource group, "net-a" and "net-b".

Create a vnet peering:

$ az network vnet peering create --subscription aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee --resource-group mhy20190410 --vnet net-a --name net-b-peering --remote-vnet /subscriptions/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee/resourceGroups/mhy20190410/providers/Microsoft.Network/virtualNetworks/net-b --allow-vnet-access
{
  "allowForwardedTraffic": false,
  "allowGatewayTransit": false,
  "allowVirtualNetworkAccess": true,
  "etag": "W/\"5c7f3ea1-f893-411f-a593-6f4c2a7a1965\"",
  "id": "/subscriptions/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee/resourceGroups/mhy20190410/providers/Microsoft.Network/virtualNetworks/net-a/virtualNetworkPeerings/net-b-peering",
  "name": "net-b-peering",
  "peeringState": "Initiated",
  "provisioningState": "Succeeded",
  "remoteAddressSpace": {
    "addressPrefixes": [
      "10.0.2.0/24"
    ]
  },
  "remoteVirtualNetwork": {
    "id": "/subscriptions/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee/resourceGroups/mhy20190410/providers/Microsoft.Network/virtualNetworks/net-b",
    "resourceGroup": "mhy20190410"
  },
  "resourceGroup": "mhy20190410",
  "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings",
  "useRemoteGateways": false
}

The help text for option "--allow-vnet-access" as output by "az network vnet peering create -h" states:

    --allow-vnet-access            : Allows VMs in the remote VNet to access all VMs in the local
                                     VNet.

According to this help text, VMs in net-b will have access to all VMs in net-a.

Whereas the Azure portal displays the following:

Which indicates that VMs in net-a will have access to VMs in net-b, i.e. the opposite of what the CLI help states.

Expected behavior
I believe the help text for option "--allow-vnet-access" should say the exact opposite.

Environment summary

Additional context

[tjprescott]

Thanks for the report @mhyllander! I'll take a look.

[mhyllander]

In addition, the help text for option "--allow-forwarded-traffic" says:

    --allow-forwarded-traffic      : Allows forwarded traffic from the VMs in the remote VNet.

This also looks strange. According to the portal:

This states that the option will allow traffic not originating in net-a to be forwarded to net-b.

[tjprescott]

@MikhailTryakhov can you give clarification on this? The CLI help was adapted from the help text in the Swagger specs. Here's the text in the Python SDK (which is from the Swagger)

allow_virtual_network_access: Whether the VMs in the linked virtual
     network space would be able to access all the VMs in local Virtual network
     space.
 
 allow_forwarded_traffic: Whether the forwarded traffic from the VMs
     in the remote virtual network will be allowed/disallowed.

If this is incorrect, I'm happy to fix the CLI text, but it should also be fixed in the Swagger.

[MikhailTryakhov]

@Amo18 can you please fix swagger cause you are an owner of Vnets

[tjprescott]

@Amo18 if I can get confirmation on whether Swagger or Portal is correct, I can make the update in CLI if needed.

[Am018]

Agreed, this needs to be fixed in the Swagger document.