Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-33397

Openshift uncordoned compute-node that was intentionally cordoned

XMLWordPrintable

    • +
    • Moderate
    • No
    • MCO Sprint 256, MCO Sprint 257
    • 2
    • False
    • Hide

      None

      Show
      None
    • Hide
      * Previously, machine config pools (MCP) that had a higher `maxUnavailable` value than the cluster has unavailable nodes, cordoned nodes could be erroneously selected as an update candidate. This fix adds a node readiness check in the node controller so that cordoned nodes are queued for an update. (link:https://issues.redhat.com/browse/OCPBUGS-33397[*OCPBUGS-33397*])
      Show
      * Previously, machine config pools (MCP) that had a higher `maxUnavailable` value than the cluster has unavailable nodes, cordoned nodes could be erroneously selected as an update candidate. This fix adds a node readiness check in the node controller so that cordoned nodes are queued for an update. (link: https://issues.redhat.com/browse/OCPBUGS-33397 [* OCPBUGS-33397 *])
    • Bug Fix
    • Done

      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:

              djoshy David Joshy
              rhn-support-adv Arpitha DV
              Sergio Regidor de la Rosa Sergio Regidor de la Rosa
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: