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

Hosted control planes (HyperShift) should consume recomended updates from OSUS

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Major Major
    • openshift-4.13
    • None
    • None
    • Hosted control planes (HyperShift) should consume recomended updates from OSUS
    • BU Product Work
    • False
    • None
    • False
    • Not Selected
    • To Do
    • OCPSTRAT-52 - Upgrade to OpenShift 4.13
    • OCPSTRAT-52Upgrade to OpenShift 4.13
    • 0% To Do, 0% In Progress, 100% Done

      Problem Overview

      Hosted control planes with HyperShift introduce a new architecture for OpenShift where the control plane and workers are decoupled and are represented but two distinct APIs, namely the `HostedCluster` API to represent cluster and control plane configuration and `NodePool` to expose lifecycle configuration. 

      Today we set the channel-specific field to empty as the default CVO configuration does not apply to this new architecture. As a result, Cinncinati and the edged graph do not apply. The alternative provided today with HyperShift is guard railing versions within the HyperShift's operator code-base; while this works short-term, it can result in added complexity and even duplication long-term. 

      Goals

      This effort aims to evaluate the changes required for parity between the existing CVO + Cinncinati with the newly introduced HyperShift architecture.  Furthermore, one important outcome of this work is a clearly articulated spec of proposed changes to achieve partiy or suggestion of alternative methods. 

      Notes

      A possible implementation of this would result in adding a channel field to the spec of the HostedCluster resource and reporting availableUpdates in its status.
      We should also decide whether the same should be done for NodePools (channel + status)
      OR whether we should adopt a simpler pattern:

      • NodePools can only be created by pointing to the same release image as the HostedCluster
      • When updating a NodePool we can only update to the same release image as the HostedCluster. (for this last one we need to validate whether it's ok for nodepools to skip a minor release in the case of inplace upgrades)

       

          There are no Sub-Tasks for this issue.

              lmohanty@redhat.com Lalatendu Mohanty
              azaalouk Adel Zaalouk
              Alberto Garcia Lamela, Cesar Wong, Derek Carr, Lalatendu Mohanty, Naveen Malik
              Yang Yang Yang Yang
              Votes:
              0 Vote for this issue
              Watchers:
              16 Start watching this issue

                Created:
                Updated:
                Resolved: