-
Bug
-
Resolution: Done-Errata
-
Normal
-
4.13
-
Moderate
-
No
-
MCO Sprint 257
-
1
-
False
-
-
On MCP with higher maxUnavailable than unavailable nodes, cordoned nodes were mistakenly selected as an update candidate, depending on the order of the node list. This fix will always ensure cordoned nodes will not be queued for an update.
-
Bug Fix
-
In Progress
This is a clone of issue OCPBUGS-37629. The following is the description of the original issue:
—
This is a clone of issue OCPBUGS-37460. The following is the description of the original issue:
—
This is a clone of issue OCPBUGS-33397. The following is the description of the original issue:
—
Description of problem:
Node has been cordoned manually.After several days, machine-config-controller uncordoned the same node after rendering a new machine-config.
Version-Release number of selected component (if applicable):
4.13
Actual results:
The mco rolled out and the node was uncordoned by the mco
Expected results:
MCO treat unscedhulable node as not ready for performing update. Also, it may halt update on other nodesĀ in the pool based on what maxUnavailable is set for that pool
Additional info:
- clones
-
OCPBUGS-37738 Openshift uncordoned compute-node that was intentionally cordoned
- Closed
- depends on
-
OCPBUGS-37738 Openshift uncordoned compute-node that was intentionally cordoned
- Closed
- links to
-
RHBA-2024:5444 OpenShift Container Platform 4.13.z bug fix update