-
Spike
-
Resolution: Done
-
Critical
-
None
-
None
-
None
-
False
-
None
-
False
-
If docs needed, set a value
-
Unset
-
?
-
No
-
?
-
False
-
?
-
?
-
ToDo
-
Untriaged
-
Not Supported
-
---
-
---
-
-
-
0
-
Untriaged
Impact statement for the OCPBUGS-49994 series:
Which 4.y.z to 4.y'.z' updates increase vulnerability?
- Any upgrade to 4.18.* will fail.
Which types of clusters?
There is no way to identify the cluster with PromQL, a cluster admin has to manually check.
The cluster network configuration is with:
- "OVNKubernetes" type, and
- multiple IP address pools in the same IP family, e.g., IPv4 or IPv6 in the cluster's network.
Show the network type: OVNKubernetes
$ oc get network.config/cluster -o yaml | yq -r '.spec.networkType' OVNKubernetes
In this example, there are two IPv4 IP address pools:
$ oc get network.config/cluster -o yaml | yq -y '.spec.clusterNetwork' - cidr: 10.128.0.0/14 hostPrefix: 23 - cidr: 10.254.0.0/16 hostPrefix: 24
A cluster with only one cluster network configured is not affected.
A cluster with standard dual-stack network is not affected.
What is the impact? Is it serious enough to warrant removing update recommendations?
- Upgrade will fail with the ovnkube-node pods stuck in CrashLoopBackOff state. Those pods can be found with the following command:
$ oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node
- The cluster is in a bad state where new pods cannot be created successfully.
How involved is remediation?
- There is no remediation yet.
Is this a regression?
- Yes. Upgrade to 4.18.z
- blocks
-
OCPBUGS-49994 ovnkube-controller stuck in crashloopbackoff when upgrading to 4.18 with clusterNetwork set to multiple networks of the same IP family
-
- Verified
-
- links to