Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-4547

OpenShift patching banner include waiting till patching of all the nodes

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • None
    • False
    • None
    • False
    • Not Selected

      1. Proposed title of this feature request

      OpenShift patching banner include waiting till patching of nodes   

      2. What is the nature and description of the request?

      Ever since 4.12 customer removed their old patching banner and used the Red Hat banner that appears when an OCP cluster is patching.

      The Red Hat banner is removed when the clusterversion is patched / updated to a new version, however the nodes are still being patched / rebooted

      Because the Red Hat banner is already removed, customer did not know why their workload was moved to another worker node and asked questions about what was going on?

      When there is a banner present, atleast the customer knows that workload is being moved due to the patching process, which in my view includes patching of the nodes.

      If the Red Hat banner is removed, customer assumes patching is done.
      3. Why does the customer need this? (List the business requirements here)

      So the customer knows that when they notice a workload shift / move that this is due to patching.
      4. How would you like to achieve this? 

      Make the Red Hat patch banner wait for the MCP pools to be healthy / updated before removing the patching banner

      This can be done by letting the patching banner stay longer, or change it to a banner that indicates nodes are being rebooted due to patching process.
      5. Tests for Successful Implementation

      A Red Hat patch banner that is only removed after: clusterversion patched and all MCP pools healthy / updated.

       

              rh-ee-smodeel Subin M
              rhn-support-amulmule Akash Mulmuley (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: