Bug 2060334 - Azure VNET lookup fails when the NIC subnet is in a different resource group
Summary: Azure VNET lookup fails when the NIC subnet is in a different resource group
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.10
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 4.11.0
Assignee: Ben Bennett
QA Contact: Mike Fiedler
URL:
Whiteboard:
Depends On:
Blocks: 2062133
TreeView+ depends on / blocked
 
Reported: 2022-03-03 11:01 UTC by David Newman
Modified: 2022-08-10 10:52 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-08-10 10:52:11 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift cloud-network-config-controller pull 26 0 None open Fix Azure VNET lookup when the NIC's subnet is in a different resource group 2022-03-03 11:01:20 UTC
Red Hat Product Errata RHSA-2022:5069 0 None None None 2022-08-10 10:52:41 UTC

Description David Newman 2022-03-03 11:01:21 UTC
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.

Comment 3 Mike Fiedler 2022-03-16 00:57:02 UTC
@dnewman@redhat.com   I successfully upgraded 4.10.4 to latest 4.11 with this bz fix with network resources in their own rg.

oc get infrastructures.config.openshift.io cluster  -ojsonpath='{.status.platformStatus}' | jq                                                                                                           
{
  "azure": {
    "cloudName": "AzurePublicCloud",
    "networkResourceGroupName": "mifiedle-315f-rg",
    "resourceGroupName": "mifiedle-315f-kdjxg-rg"
  },
  "type": "Azure"
}

I also see the egressip annotation:

metadata:
  annotations:
    cloud.network.openshift.io/egress-ipconfig: '[{"interface":"mifiedle-315f-kdjxg-worker-southcentralus1-lv5h4-nic","ifaddr":{"ipv4":"10.0.0.0/16"},"capacity":{"ip":255}}]'


Anything else I should be looking for?

Comment 4 David Newman 2022-03-16 09:47:54 UTC
@mifiedle@redhat.com nope, that looks good to me, because before the fix the lookup would failed and the annotation would not have been added.

Comment 5 Mike Fiedler 2022-03-16 11:57:22 UTC
Verified on 4.11.0-0.nightly-2022-03-15-060211.   See comment 3 for details.

Comment 8 errata-xmlrpc 2022-08-10 10:52:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: OpenShift Container Platform 4.11.0 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:5069


Note You need to log in before you can comment on or make changes to this bug.