Document limitations and collect information to plan future work needed to accommodate HyperShift architecture - in OSSM and elsewhere.

• Setup or acquire a HyperShift instance for testing Gateway API with OSSM
• Determine which components will need special handling
  • What changes are we making for Ingress and Routers on HyperShift?
  • What changes are we making for OSSM components on HyperShift?
  • Network & Trust segmentation
  • Multi-arch support
  • Control planes as pods
• Run tests to determine compliance within a HyperShift architecture, possibly including Gateway API compliance tests and OpenShift E2E tests
• Deliver documentation on future work needed to accommodate HyperShift

Notes:

"HyperShift is a middleware for hosting control planes at scale that solves for cost and time to provision, as well as portability cross cloud with strong separation of concerns between management and workloads." 

HyperShift documentation

Main goals of HyperShift (engineering)

• API to express intent to create OCP clusters with a hosted control plane topology on existing infrastructure.
• Decouple control and data plane.

Design invariants

• Communication between management cluster and a hosted cluster is unidirectional. A hosted cluster has no awareness of a management cluster.
• Communication between management cluster and a hosted cluster is only allowed from within each particular control plane namespace.
• Compute worker Nodes should not run anything beyond user workloads.
• A hosted cluster should not expose CRDs, CRs or Pods that enable users to manipulate HyperShift owned features.
• HyperShift components should not own or manage user infrastructure platform credentials.