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.