TLDR: In OCP 4.22, we want to announce GA for:

• Day-1 installer with 13 pre-selected Day-2 operators for OpenShift Virtualization w/o an external registry
• Day-2 add a new node w/o an external registry

Day-2 upgrade/update with an external registry provided by a customer

OCP feature name: NoRegistryClusterInstall

The installation process for the OpenShift Virtualization Engine (OVE) has been identified as a critical area for improvement to address customer concerns regarding its complexity compared to competitors like VMware, Nutanix, and Proxmox. Customers often struggle with disconnected environments, operator configuration, and managing external dependencies, making the initial deployment challenging and time-consuming. 

To resolve these issues, the goal is to deliver a streamlined, opinionated installation workflow that leverages existing tools like the Agent-Based Installer, the Assisted Installer, and the OpenShift Appliance (all sharing the same underlying technology) while pre-configuring essential operators and minimizing dependencies, especially the need for an image registry before installation.

Additionally, the offered functionality has to cover Day-2 (an adding new nodes) in a disconnected and (external) registryless environment.

By focusing on enterprise customers, particularly VMware administrators working in isolated networks, this effort aims to provide a user-friendly, UI-based installation experience that simplifies cluster setup and ensures quick time-to-value.

Objectives and Goals

Primary Objectives

• Simplify the OpenShift Virtualization installation and Day-2 (upgrade and adding new nodes) processes to reduce complexity for enterprise customers coming from VMware vSphere.
  • Day-2 upgrade without an external registry will be delivered separately. A customer can upgrade the cluster using InternalReleaseImage CR for switching to an external registry
• Enable installation and adding new nodes in disconnected environments with minimal prerequisites.
• Eliminate the dependency on a pre-existing image registry in disconnected installations and adding new nodes.
• Provide a user-friendly, UI-driven installation experience for users used to VMware vSphere.

Goals

• Deliver an installation experience leveraging existing tools like the Agent-Based Installer, Assisted Installer, and OpenShift Appliance, i.e. the Assisted Service.
• Pre-configure essential operators for OVE and minimize external day 1 dependencies (see OCPSTRAT-1811 "Agent Installer interface to install Operators") 
• Ensure successful installation/adding new nodes in disconnected environments with standalone OpenShift, with minimal requirements and no pre-existing registry

Personas

Primary Audience 

VMware administrators transitioning to OpenShift Virtualization in isolated/disconnected environments.

Pain Points

• Lack of UI-driven workflows; writing YAML files is a barrier for the target user (virtualization platforms admins)
• Complex setup requirements (e.g., image registries in disconnected environments).
• Difficulty in configuring network settings interactively.
• Lack of understanding when to use a specific installation method
• Hard time finding the relevant installation method (docs or at console.redhat.com)

Technical Requirements

Use case:

OpenShift installation//adding new nodes with WebUI in a disconnected environment without an external image registry (all necessary components (RHCOS, OpenShift, and selected Day-2 operators) are a part of the mounted ISO image) for all Openshift deployments deployments:

• Single Node OpenShift,
• 3-Node with additional worker nodes
• Standard OpenShift cluster with dedicated control plane nodes

Additionally, support for x86_64 architecture (Aarch64, S390 and IBM-Z can be delivered as separate features after GA).

2 use cases:

• Agent Installer for OCP-Virt for Day-1 and Day-2 (adding a new node)
• Agent Installer for OCP-Virt for Day-1 and traditional approach for Day-2 with an external registry provided by a customer

Image Registry Simplification

• Eliminate the dependency on an existing external image registry for disconnected environments.
• Support a workflow similar to the OpenShift Appliance model, where users can deploy a cluster without external dependencies.

Agent-Based Installer Enhancements

• Extend the existing UI to capture all essential data points (e.g., cluster details, network settings, storage configuration) without requiring YAML files.
• Install without a pre-existing registry in disconnected environment
• Install required operators for virtualization (OpenShift Virtualization Reference Implementation Guide v1.0.2)
• List of Operators:
  • OpenShift Virtualization Operator
  • Node Health Check (NHC) Operator
  • Fence Agents Remediation (FAR) Operator
  • Node Maintenance Operator (NMO)
  • Loki
  • OpenShift Logging Operator
  • Cluster Observability Operator(COO)
  • MetalLB
  • Migration Toolkit for Virtualization (MTV)
  • Kube Descheduler Operator
  • NUMA Resources Operator
  • NMState Operator
  • OADP

• Note: we need each operator owner to enable the operator to allow its installation via the installer. We won't block the release due to not having the full list of operators included and they'll be added as required and prioritized with each team.

User experience requirements

The first area of focus is a disconnected environment. We target these environments with the Agent-Based Installer. 

The current docs for installing on disconnected environment are very long and hard to follow.

Generala

• Productization of OCPSTRAT-1985 TP features
  • Assisted UI
  • Appliance

• Build Release pipeline for generic ISO
• Build Release pipeline for “above-the-sea” UI
• Support for OLM operator

Connected phase

• It will be a new option in the Assisted Installer wizard.
• Selecting the new option, a user will receive a simple wizard leading to a customized ISO download.
• ISO will be generated upfront for each Z-release with the latest version of Day-2 operators:
  • Minimum x86_64 architecture

Disconnected phase

• Installation:
  • Deploy: SNO, 3-Node with additional workers, Standard Cluster with dedicated control plane nodes
    • Including 4th and 5th control plane node
  • Possibility to select operators from the predefined list during the installation process

• Upgrade/update:
  • Day-2 upgrade without an external registry will be delivered separately. A customer can upgrade the cluster using InternalReleaseImage CR for switching to an external registr

• Expand the cluster with new nodes (scale out and node failure scenarios)
  • Scale out scenarios worker nodes for below deployments:
    • 3-Node with 0..n workers
    • Standard OpenShift cluster with dedicated control plane nodes
  • Failure scenarios:
    • Worker node failure
    • Control Plane node failure (minimum - document the manual procedure)
  • Adding new nodes without an external registry
• Security:
  • Authorisation and authentication of Assisted Service on a rendezvous node
  • Admin - AI-UI session protection (HTTPS, credentials to access UI) during a cluster installation

Definition of done

• Functionality described above delivered, tested by QE, and documented.

Open question

• Installation monitoring - Once the rendezvous node is rebooted., it may require several minutes between the rendezvous reboot and when the console is effectively available, and during this “blackout” period, the user will not have any way to detect/spot an eventual issue
• Disaster Recovery

Out of scope

• Shared storage solution which should be provided by a customer

Links:

• Agent-Installer Installation UI for OpenShift Virtualization - update
• Simplified Disconnected Installation
• This document written by Zane Bitter as the Staff Engineer of this area contains an interactive workflow proposal.

• PRD Installation UX for OpenShift Virtualization (and notes from regular meetings)