Uploaded image for project: 'OpenShift Hosted Control Plane'
  1. OpenShift Hosted Control Plane
  2. HOSTEDCP-520

Document Support & Compatibility Matrix for HyperShift

    XMLWordPrintable

Details

    • Epic
    • Resolution: Done
    • Blocker
    • openshift-4.12
    • openshift-4.12
    • None
    • Support & Compatibility Matrix for HyperShift
    • False
    • None
    • False
    • OCPSTRAT-591HyperShift Core Component Readiness for GA - Part I
    • Not Selected
    • To Do
    • OCPSTRAT-591 - HyperShift Core Component Readiness for GA - Part I
    • 100
    • 100% 100%
    • 0
    • 0
    • 0
    • Approved

    Description

      Overview 

       Before the GA of HyperShift in any management model (managed/self-managed), we will need to answer:

      • Which Infras are supported both for CP and workers
      • Which versions are supported?
      • The lifecycle for upgrades and maintenance. 

      Support Status today 

      • A given HO release targets a given kube/ocp version.
      • Just to clarify this is a minor (eg. 4.10) version. Only initially, we may claim support of a specific Z release and later. (eg. 4.10.7)
      • A HO should support N, N-1, N-2 kube/ocp minor versions by policy contract. 
      • N-1 and N-2 are supported as long as we generally claim support for them in HyperShift (eg., in the 4.10 dev preview, we won’t support 4.9 or 4.8)
      • How do we enforce this? Do we just place a condition on the hosted cluster and not process it if it has a version outside the supported range?
      • What happens when I have N-2 control planes and I want to upgrade HO to N+1?
        We need to clarify when IBM is upgrade to 4.10{_}
        {}Decide which CI tests we will need to enforce this{_}
      • A HO does only best effort to support future kube/ocp versions, e.g N+1.
      • Should we prevent this by default but allow it only via explicit override? It’s not something we will have tested.
      • This we must enforce and gate in CI. (A HO supports N, N-1, N-2 kube/ocp versions).
      • How can we balance the tests we want with timely feedback on PRs? 
      • Should all tests be presubmits or should we also rely on periodic tests?
      • What about tests for upgrading the hypershift operator?
      • If you want to run kube/ocp N+1, we can force you to upgrade the HO

      For GA readiness

      • We should have CI profile for AWS/Agent/KubeVirt as well as automated test cases. 
      • The test should include the e2e experience, exactly how it will be used in the product (MCE). 
      • We are confident with our support lifecycle statements. 

       
       
       

      Attachments

        Issue Links

          Activity

            People

              rhn-support-heli He Liu
              azaalouk Adel Zaalouk
              Laura Hinson Laura Hinson
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: