Description of problem:
In setups where the network resources, VNET and subnets, are in a different resource group to the cluster resources, i.e. the NIC in this instance, the VNET lookup fails.

$ oc get infrastructures.config.openshift.io cluster  -ojsonpath='{.status.platformStatus}' | jq
{
  "azure": {
    "cloudName": "AzurePublicCloud",
    "networkResourceGroupName": "v4-eastus",
    "resourceGroupName": "aro-dnewman-test-4-10"
  },
  "type": "Azure"
}

the error message that is being logged is: "The Resource 'Microsoft.Network/virtualNetworks/dev-vnet' under resource group 'aro-dnewman-test-4-10' was not found", because it is in the 'v4-eastus' resource group.


Version-Release number of selected component (if applicable):
$ oc get clusterversion
NAME      VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.10.0-rc.6   True        False         29h     Cluster version is 4.10.0-rc.6

How reproducible:
Fails every time the VNET is not in the same resource group as the VM NIC.

Steps to Reproduce:
Upgrade an ARO cluster from 4.9 to 4.10 or any OCP cluster with the allocated VNET in a different resource group.

Actual results:
The nodes are never annotated with 'cloud.network.openshift.io/egress-ipconfig' information.

Expected results:
The nodes get the 'cloud.network.openshift.io/egress-ipconfig' annotations with the subnets and IP capacities.

Additional info:
I have created a PR that uses the subnet ID to parse the allocated resource group that fixes the issue.