Feature Overview

Hypershift is a cluster-as-a-service provisioning tool, the end-product for HyperShift is a working cluster with externalized and centrally managed control-planes. HyperShift is not an orchestrator, and neither it is an immediate end-user facing management layer, it is rather a consumable that takes cluster requests and gives clusters back as a response.

That said, it is important to expose a relaxed and configurable API up to cluster orchestrators to accommodate each of their usage models. That flexibility should be adopted with care however, with power comes great responsibility

Background, and strategic fit

The benefits of externally managed control planes are highlighted in the Market Problem for HyperShift [1]. These benefits might make sense to reap for users who have environments that match the characteristics of the HyperShift value proposition. Those users might be using different North-bound orchestrator for directly interacting with their clusters, making sure HyperShift cover the needs of those orchestrators improves user-experience by a great factor and ensures a homogenous experience across all the Northbound orchestrators.

Goal(s)

The goal of these features is to answer important questions around the HyperShift APIs:

• How do we integrate with similar upstream initiatives for cluster-lifecycle management (i.e., Cluster API)?
• What fields do we want to expose in our facing API (e.g., networking, provider configuration, security, storage, add-ons, etc)?
• How do we go about machine-management and autoscaling, how will HyperShift's NodePool resource adapt to those needs?

More details about those questions can be viewed in the figure below:

Notes

Collaboration with various teams is likely required to get to a stable looking API. Furthermore, sync with similar products (e.g., ROSA) on how they expose things like cloud-provider credentials in their API might be needed.  

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content Strategy.
• What concepts do customers need to understand to be successful in [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or Release Note)?

References

[1] https://issues.redhat.com/browse/OCPPLAN-3783