Goal
Define end to end user journeys from OCP to ACM for HyperShift clusters. This story will focus on the Cluster Service Consumer persona (see below).

Background
HyperShift workflows require the disabling or removing of functions at an OCP cluster level and adding the ability to edit those details inside of ACM instead.

Many of these settings exist in OSD today (see screenshots below). Use those as a starting point, but improve UX where needed.

Near Term Goal

• Making the OpenShift console compatible with HyperShift (e.g., remove the ability to configure Machines,..)
• Having a point of reference from the console to the high-layer client (e.g., ACM for self-managed, OCM for managed) for the things that is not configuration from the console but configurable from the NB client (e.g., ACM)
• Having an experience for lifecycling HyperShift HostedClusters (in ACM and OCM)

Future Goal

• An experience for lifecycling management clusters (in ACM and OCM)
• Keep the console updated with the client point of reference

Personas/Roles
Cluster Service Provider - the user hosting cluster control planes, responsible for up-time. UI for fleet wide alerts, configuring AWS account to host control planes in, user provisioned infra (host awareness of available compute), where to pull VMs from has cluster admin management

Cluster Service Consumer - the user empowered to request control planes, request workers, and drive upgrades or modify externalized configuration.  Likely not empowered to manage or access cloud creds or infrastructure encrpytion keys.

Cluster Instance Admin - the user with cluster-admin role in the provisioned cluster, but may have no power over when/how cluster is upgraded or configured.  May see some configuration projected into the cluster in read-only fashion.

Cluster Instance User / Consumer - maps to standalone OCP

Requirements

• Identify the functionality that will be removed from OCP and editable in ACM:
  • MachineConfig and MachineConfigPool - should not be editable, they should be either removed or hidden when the cluster is spawned using HyperShift depending on RBAC.
  • Cluster Settings - say control plane is externally managed, make read only.
  • Cluster Settings - Configuration resources should be read only or hidden depending on RBAC.
  • Some resources should go in an allowlist. Most will be hidden.
• Review getting started steps
• Identify other gaps.

Capture other strategic considerations we will need to address like:

• Define an overall strategy for OCP - do we disable or completely hide the functionality that users can no longer edit in console? Do we use RBAC to make that decision?
• Can we send users directly to ACM to edit functionality that we need to disable in OCP (we may only be able to drill down due to security reasons).
• We need a way to make it clear that the user is viewing a HyperShift cluster and that these settings are now managed in ACM.

Resources

• HyperShift Overview & Outlook Deck
• HyperShift Consumption and Early Ops Options
• HyperShift + OpenShift Console Plan for GA
• Standalone HyperShift Consumption Through ACM - Deep-dive
• API availability

Deliverables
The outcome of this work will outline actionable stories for designers to take on.
Miro: https://miro.com/app/board/o9J_lisgrSk=/
Design Doc: https://docs.google.com/document/d/1k76JtRRHBdCCEjHPqKcYvbNVsuaGmRhWDLESWIm0mbo/edit#

The HyperShift Taskforce (Contacts)

• PM: Scott Berens and Sho (ACM), Ali Mobrem (Console), Adel Zaalouk (HyperShift), Greg Sheremeta (OCM)
• UX:
  • Console: Megan
  • ACM/OCM: Matt Carleton, Lisa Lyman, Eric Fried
• ACM Backend: Joshua Packer
• Architects: Derek Carr (OpenShift)