-
Spike
-
Resolution: Unresolved
-
Critical
-
None
-
None
-
None
-
None
-
False
-
-
False
-
None
-
None
-
None
-
None
Note that the impact from this card is wider than CORENET-4908 as it does not need multiple compute pools on the cluster.
Impact statement for the OCPBUGS-36688 series:
Which 4.y.z to 4.y'.z' updates increase vulnerability?
- Updates from 4.14.z to 4.15.z'
Which types of clusters?
- IPsec enabled OCP clusters which uses OVN-K for pod networking and there is a paused worker MCP during the upgrade
What is the impact? Is it serious enough to warrant removing update recommendations?
- During the upgrade, when any of the worker pool is in paused state, then network cluster operator doesn't get upgraded into new version and just blocked on previous version itself until worker pool is unpaused. It blocks the control plane to be upgraded to the desired version.
- The network operator accidentally disables IPsec in the OVN during the upgrade, so it can cause intermittent pod traffic failure during upgrade.
How involved is remediation?
- After performing a Control Plane Only update as mentioned here, user will unpause the worker pool as mentioned in the step 10.
Is this a regression?
- Yes, This is kind of new behavior introduced in 4.15 due to usage of Machine Configs for IPsec deployment.
- blocks
-
OCPBUGS-52280 [release-4.19] Unexpected Behavior During Cluster Upgrade (4.14.23 to 4.15.15) for the ovn-ipsec-host pods.
-
- Closed
-
- links to