Uploaded image for project: 'OpenShift Over the Air'
  1. OpenShift Over the Air
  2. OTA-922

In Docs, motivate duration of control-plane component updates


    • Icon: Story Story
    • Resolution: Done
    • Icon: Minor Minor
    • None
    • None
    • None

      OCP/Telco Definition of Done
      Epic Template descriptions and documentation.

      <--- Cut-n-Paste the entire contents of this description into your new Epic --->

      Epic Goal

      OSDOCS-3300 added docs like:

      The Cluster Version Operator (CVO) retrieves the target update release image and applies to the cluster. All components which run as pods are updated during this phase, whereas the host components are updated by the Machine Config Operator (MCO). This process might take 60 to 120 minutes.

      That's a long time, and folks can wonder why it takes so long. OTA-474 is bringing in some documentation explaining runlevels and manifest name patterns, etc. That will establish "and update involves a combination of serial and parallel pivots". This ticket aims to follow up with an explanation of how we get from there to the ~hour timespan. But we want the declaration to not go stale quickly. We can probably pick out a few slow operators (Kube API server, networking, and DNS) and explain why those take some time to perform a zero-disruption update, without making brittle commitments about the order in which those changes roll out.

            rhn-support-skopacz Sebastian Kopacz
            rh-ee-smodeel Subin MM
            Jia Liu Jia Liu
            0 Vote for this issue
            5 Start watching this issue