Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 4. Installing with the Assisted Installer web console

After you ensure the cluster nodes and network requirements are met, you can begin installing the cluster.

4.1. Preinstallation considerations

Before installing OpenShift Container Platform with the Assisted Installer, you must consider the following configuration choices:

  • Which base domain to use
  • Which OpenShift Container Platform product version to install
  • Whether to install a full cluster or single-node OpenShift
  • Whether to use a DHCP server or a static network configuration
  • Whether to use IPv4 or dual-stack networking
  • Whether to install OpenShift Virtualization
  • Whether to install Red Hat OpenShift Data Foundation
  • Whether to install multicluster engine for Kubernetes
  • Whether to integrate with the platform when installing on vSphere or Nutanix
  • Whether to install a multi-architecture compute cluster

4.2. Setting the cluster details

To create a cluster with the Assisted Installer web user interface, use the following procedure.

Procedure

  1. Log in to the Red Hat Hybrid Cloud Console.
  2. On the Red Hat OpenShift tile, click OpenShift.
  3. On the Red Hat OpenShift Container Platform tile, click Create cluster.
  4. Click the Datacenter tab.
  5. Under Assisted Installer, click Create cluster.
  6. Enter a name for the cluster in the Cluster name field.

  7. Enter a base domain for the cluster in the Base domain field. All subdomains for the cluster will use this base domain.

    Note

    The base domain must be a valid DNS name. You must not have a wildcard domain set up for the base domain.

  8. From the OpenShift version dropdown list, select the version that you want to install and click Select. By default, the dropdown lists the latest OpenShift version. If you need an older version that is not displayed, click Show all available versions at the bottom of the list, and use the search box to find it.

    Important
    • For a multi-architecture compute cluster installation, select OpenShift Container Platform 4.12 or later, and use the -multi option. For instructions on installing a multi-architecture compute cluster, see Installing multi-architecture compute clusters.
    • For IBM Power® and IBM Z® platforms, only OpenShift Container Platform 4.13 and later is supported.
    • If you are booting from an iSCSI drive, select OpenShift Container Platform version 4.15 or later.

  9. Optional: Assisted Installer defaults to using x86_64 CPU architecture. If you are installing OpenShift Container Platform on a different architecture, select the architecture to use. Valid values are arm64, ppc64le, and s390x. Remember that some features are not available with arm64, ppc64le, and s390x CPU architectures.

    Important

    For a multi-architecture compute cluster installation, you can use x86_64 or 64-bit ARM CPU architecture for the control plane nodes. Automatic conversion from x86_64 to 64-bit ARM is only supported on Amazon Web Services (AWS). For instructions on installing a multi-architecture compute cluster, see Installing multi-architecture compute clusters.

  10. Optional: The Assisted Installer already has the pull secret associated to your account. If you want to use a different pull secret, select Edit pull secret.

  11. Optional: If you are installing OpenShift Container Platform on a third-party platform, select the platform from the Integrate with external partner platforms list. Valid values are Nutanix, vSphere or Oracle Cloud Infrastructure. Assisted Installer defaults to having no platform integration.

    Note
    • Assisted Installer supports Oracle Cloud Infrastructure (OCI) integration from OpenShift Container Platform 4.14 and later.
    • For details on each of the external partner integrations, see Additional Resources.

  12. From the Number of control plane nodes field, optionally change the default value of three control plane nodes for your installation. The possible options are 1 (single-node OpenShift), 3, 4, or 5.

    Important
    • The system supports 4 or 5 control plane nodes from OpenShift Container Platform 4.18 and later, on a bare metal or user-managed networking platform with an x86_64 CPU architecture. For details, see About specifying the number of control plane nodes.
    • Currently, single-node OpenShift is not supported on IBM Z® and IBM Power® platforms.

  13. Optional: Select Include custom manifests if you have at least one custom manifest to include in the installation. A custom manifest has additional configurations not currently supported in the Assisted Installer. Selecting the checkbox adds the Custom manifests step to the wizard, where you upload the manifests.

    Important
    • If you are installing OpenShift Container Platform on the Oracle Cloud Infrastructure (OCI) third-party platform, it is mandatory to add the custom manifests provided by Oracle.
    • If you have already added custom manifests, clearing the Include custom manifests checkbox automatically deletes them all. You must confirm the deletion.

  14. Optional: The Assisted Installer defaults to DHCP networking. If you are using a static IP configuration, bridges or bonds for the cluster nodes instead of DHCP reservations, select Static IP, bridges, and bonds. Selecting the checkbox adds the Static network configurations step to the wizard. For details, see Configuring static networks.

    Important

    A static IP configuration is not supported in the following scenarios:

    • OpenShift Container Platform installations on Oracle Cloud Infrastructure.
    • OpenShift Container Platform installations on iSCSI boot volumes.

  15. Optional: If you want to enable encryption of the installation disks, under Enable encryption of installation disks you can select one of the following:

    • For single-node OpenShift, select Control plane node, worker.

    • For multi-node clusters, select Control plane nodes to encrypt the control plane node installation disks. Select Workers to encrypt worker node installation disks.

      Important

      You cannot change the base domain, the single-node OpenShift checkbox, the CPU architecture, the host’s network configuration, or the disk-encryption after installation begins.

Additional resources

4.3. Configuring static networks

The Assisted Installer supports IPv4 networking with SDN up to OpenShift Container Platform 4.14. From OpenShift Container Platform 4.15 and later releases, the Assisted Installer supports IPv4 and dual stack networking with IPv4 as primary (OVN only). The Assisted Installer supports configuring the network with static network interfaces with IP address-to-MAC address mapping.

The Assisted Installer also supports configuring host network interfaces with the NMState library, a declarative NetworkManager API for hosts. You can use NMState to deploy hosts with static IP addressing, bonds, VLANs and other advanced networking features.

Note

For installations on IBM Z® with z/VM, ensure that the z/VM nodes and vSwitches are properly configured for static networks and NMState. Also, the z/VM nodes must have a fixed MAC address assigned as the pool MAC addresses might cause issues with NMState. For more information about NMState, see NMState Declarative Network API.

4.3.1. Configuring static networks using form view

You can configure networks by using the form view or the YAML view. Select Form view for basic configurations and select YAML view for advanced configurations.

Note

To add new hosts that will use the new or edited configurations, you’ll need to regenerate the Discovery ISO in the 'Host discovery' step and boot your new hosts from it.

Procedure

  1. From the Configure via options, select Form view.

  2. Enter the network-wide configurations:

    1. Select the Networking stack type. Valid options are IPv4 and Dual stack (with IPv4 as primary).

      Important

      IPv6 is not currently supported in the following configurations:

      • Single stack
      • Primary within dual stack
    2. If the cluster hosts are on a shared VLAN, select the Use VLAN checkbox and enter the VLAN ID.

    3. Enter the network-wide IP addresses. If you selected Dual stack networking, you must enter both IPv4 and IPv6 addresses.

      1. Enter the DNS server IP address.
      2. Enter the cluster network’s IP address range in CIDR notation.
      3. Enter the default gateway IP address.

  3. Enter the host-specific configurations:

    1. If you are only setting a static IP address that uses a single network interface, use the form view to enter the IP address and the MAC address for each host.

    2. Optional: You can use bonds to combine network interfaces for increased bandwidth and ensure redundancy. Creating a bond with a static IP address aggregates two network interfaces per host.

      1. Select the Use bond checkbox.

      2. From the Bond type dropdown list, select the bond type. The default bond type is Active-Backup (1).

        Note

        For a description of the bond types, see Bonding modes.

      3. Enter the MAC address for Port 1.
      4. Enter the MAC address for Port 2.
      5. Enter the IP address for the bond.
  4. Click Next.

4.3.2. Configuring static networks using YAML view

If you use multiple interfaces or other advanced networking features, use the YAML view to enter the network state for each host that uses NMState syntax. For more information about NMState, see NMState Declarative Network API.

Note

You can only create host-specific configurations using form view.

Procedure

  1. From the Configure via options, select YAML view.
  2. Upload, drag and drop, or copy and paste a YAML file containing NMState into the editor for network configurations.
  3. In the MAC to interface name mapping fields, enter the MAC address and interface name for each host interface used in your network configuration. Each host requires the MAC to interface name mapping to run the NMState YAML on the right machine. Assisted Installer uses the MAC to interface name mapping to replace any temporary interface names with the actual names.
  4. Select the Copy the YAML content checkbox to copy the YAML content between multiple hosts.
  5. Click Add another host configuration to configure additional hosts.
  6. Click Next.

4.4. Installing Operators and Operator bundles

You can customize your deployment by selecting Operators and Operator bundles during the installation. If you require advanced options, add the Operators or bundles after you have installed the cluster.

When installing Operators and Operator bundles through the web console, the following conditions apply:

  • Some Operators are only available as part of a bundle and cannot be selected individually.
  • Some Operators can be selected either individually or as part of a bundle. If you select them as part of a bundle, you can only remove them by deselecting the bundle.
  • Some Operators are only available as standalone installations.

This step is optional.

4.4.1. Installing standalone Operators

You can select more than one standalone Operator and add Operator bundles as needed. Operators that appear greyed out are only available for installation as part of a bundle.

For instructions on installing Operator bundles, see Installing Operator bundles.

Prerequisites

Procedure

  1. On the Operators page, expand the Single Operators arrow to display the full list of Operators.

  2. Select one or more Operators from the following options:

    • Install OpenShift Virtualization

      Important

      The OpenShift Virtualization Operator requires backend storage and might automatically activate a storage Operator in the background, according to the following criteria:

      • None - If the CPU architecture is ARM64, no storage Operator is activated.
      • LVM Storage - For single-node OpenShift clusters on any other CPU architecture deploying OpenShift Container Platform 4.12 or higher.
      • Local Storage Operator (LSO) - For all other deployments.

    • Install Migration Toolkit for Virtualization

      Important

      Selecting the Migration Toolkit for Virtualization Operator automatically activates the OpenShift Virtualization Operator. For a Single-node OpenShift installation, the Assisted Installer also activates the LVM Storage Operator.

    • Install multicluster engine

      You can deploy the multicluster engine with OpenShift Data Foundation on all OpenShift Container Platform clusters.

      Important

      Deploying the multicluster engine without OpenShift Data Foundation results in the following storage configurations:

      • Multi-node cluster: No storage is configured. You must configure storage after the installation.
      • Single-node OpenShift: LVM Storage is installed.
    • Install Logical Volume Manager Storage
    • Install OpenShift Data Foundation

    • Install OpenShift AI

      Important

      The integration of the OpenShift AI Operator into the Assisted Installer is a Developer Preview feature only. Developer Preview features are not supported by Red Hat in any way and are not functionally complete or production-ready. Do not use Developer Preview features for production or business-critical workloads. Developer Preview features provide early access to upcoming product features in advance of their possible inclusion in a Red Hat product offering, enabling customers to test functionality and provide feedback during the development process. These features might not have any documentation, are subject to change or removal at any time, and testing is limited. Red Hat might provide ways to submit feedback on Developer Preview features without an associated SLA.

    • Install OpenShift sandboxed containers

      Important

      The integration of the OpenShift sandboxed containers Operator into the Assisted Installer is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

      For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

    • Install NMState

      Note

      Currently, you cannot install the Kubernetes NMState Operator on the Nutanix or Oracle Cloud Infrastructure (OCI) third-party platforms.

  3. Click Next.

4.4.2. Installing Operator bundles

You can select more than one Operator bundle together with additional Operators as needed.

For instructions on installing individual Operators, see Installing Operators.

Prerequisites

Procedure

  1. On the Operators page, select an Operator bundle:

    • Virtualization
  2. Click Next.

4.5. Adding hosts to the cluster

You must add one or more hosts to the cluster. Adding a host to the cluster involves generating a discovery ISO. The discovery ISO runs Red Hat Enterprise Linux CoreOS (RHCOS) in-memory with an agent.

Important

  • If you are installing the IBM Z® architecture, use the following table to identify the image file type:

    ArchitectureBoot methodImage type

    Logical Partition-Classic

    iPXE

    Full image file: Download a self-contained ISO image

    Logical Partition-Data Protection Manager

    ISO or iPXE

    Minimal image file: Download an ISO image that fetches content when booting up

  • ISO images are not supported for installations on IBM Z (s390x) with z/VM or logical partitioning (LPAR) nodes; use the "Booting hosts with iPXE" procedure. ISO images and iPXE are supported for installations on RHEL KVM.

Perform the following procedure for each host on the cluster.

Procedure

  1. Click the Add hosts button and select the provisioning type.

    1. Select Minimal image file: Provision with virtual media to download a smaller image that will fetch the data needed to boot. The nodes must have virtual media capability. This is the recommended method for x86_64 and arm64 architectures.

      Important

      This option is mandatory in the following scenarios:

      • If you are installing OpenShift Container Platform on Oracle Cloud Infrastructure.
      • If you are installing OpenShift Container Platform on iSCSI boot volumes.
    2. Select Full image file: Provision with physical media to download the larger full image. This is the recommended method for the ppc64le architecture and for the s390x architecture when installing with RHEL KVM.

    3. Select iPXE: Provision from your network server to boot the hosts using iPXE. This is the recommended method on IBM Z® with z/VM nodes and LPAR (both static and DPM). ISO boot is the recommended method on the RHEL KVM installation.

      Note

      If you are installing OpenShift Container Platform on RHEL KVM, in some circumstances, the VMs on the KVM host are not rebooted on first boot and need to be restarted manually.

  2. Optional: Activate the Run workloads on control plane nodes switch to schedule workloads to run on control plane nodes, in addition to the default worker nodes.

    Note

    This option is available for clusters of five or more nodes. For clusters of under five nodes, the system runs workloads on the control plane nodes only, by default. For more details, see Configuring schedulable control plane nodes in Additional Resources.

  3. Optional: If the cluster hosts are behind a firewall that requires the use of a proxy, select Configure cluster-wide proxy settings. Enter the username, password, IP address and port for the HTTP and HTTPS URLs of the proxy server.

    Note

    The proxy username and password must be URL-encoded.

  4. Optional: Add an SSH public key so that you can connect to the cluster nodes as the core user. Having a login to the cluster nodes can provide you with debugging information during the installation.

    Important

    Do not skip this procedure in production environments, where disaster recovery and debugging is required.

    1. If you do not have an existing SSH key pair on your local machine, follow the steps in Generating a key pair for cluster node SSH access.
    2. In the SSH public key field, click Browse to upload the id_rsa.pub file containing the SSH public key. Alternatively, drag and drop the file into the field from the file manager. To see the file in the file manager, select Show hidden files in the menu.
  5. Optional: If the cluster hosts are in a network with a re-encrypting man-in-the-middle (MITM) proxy, or if the cluster needs to trust certificates for other purposes such as container image registries, select Configure cluster-wide trusted certificates. Add additional certificates in X.509 format.
  6. Configure the discovery image if needed.
  7. Optional: If you are installing on a platform and want to integrate with the platform, select Integrate with your virtualization platform. You must boot all hosts and ensure they appear in the host inventory. All the hosts must be on the same platform.
  8. Click Generate Discovery ISO or Generate Script File.
  9. Download the discovery ISO or iPXE script.
  10. Boot the host(s) with the discovery image or iPXE script.

Additional resources

4.6. Configuring hosts

After booting the hosts with the discovery ISO, the hosts will appear in the table at the bottom of the page. You can optionally configure the hostname and role for each host. You can also delete a host if necessary.

Procedure

  1. From the Options (⋮) menu for a host, select Change hostname. If necessary, enter a new name for the host and click Change. You must ensure that each host has a valid and unique hostname.

    Alternatively, from the Actions list, select Change hostname to rename multiple selected hosts. In the Change Hostname dialog, type the new name and include {{n}} to make each hostname unique. Then click Change.

    Note

    You can see the new names appearing in the Preview pane as you type. The name will be identical for all selected hosts, with the exception of a single-digit increment per host.

  2. From the Options (⋮) menu, you can select Delete host to delete a host. Click Delete to confirm the deletion.

    Alternatively, from the Actions list, select Delete to delete multiple selected hosts at the same time. Then click Delete hosts.

    Note

    In a regular deployment, a cluster can have three or more hosts, and at least three of these must be control plane nodes. If you delete a host that is also a control plane node, or if there are only two hosts, you will get a message saying that the system is not ready. To restore a host, you must reboot it from the discovery ISO.

  3. From the Options (⋮) menu for the host, optionally select View host events. The events in the list are presented chronologically.

  4. For multi-host clusters, in the Role column next to the host name, you can click on the menu to change the role of the host.

    If you do not select a role, the Assisted Installer will assign the role automatically. The minimum hardware requirements for control plane nodes exceed that of worker nodes. If you assign a role to a host, ensure that you assign the control plane role to hosts that meet the minimum hardware requirements.

  5. Click the Status link to view hardware, network and operator validations for the host.
  6. Click the arrow to the left of a host name to expand the host details.

Once all cluster hosts appear with a status of Ready, proceed to the next step.

4.7. Configuring storage disks

Each of the hosts retrieved during host discovery can have multiple storage disks. The storage disks are listed for the host on the Storage page of the Assisted Installer wizard.

You can optionally modify the default configurations for each disk.

Important
  • Starting from OpenShift Container Platform 4.14, you can configure nodes with Intel® Virtual RAID on CPU (VROC) to manage NVMe RAIDs. For details, see Configuring an Intel® Virtual RAID on CPU (VROC) data volume.
  • Starting from OpenShift Container Platform 4.15, you can install a cluster on a single or multipath iSCSI boot device using the Assisted Installer.

4.7.1. Changing the installation disk

The Assisted Installer randomly assigns an installation disk by default. If there are multiple storage disks for a host, you can select a different disk to be the installation disk. This automatically unassigns the previous disk.

Note

Red Hat Enterprise Linux CoreOS (RHCOS) supports multipathing over Fibre Channel on the installation disk, allowing stronger resilience to hardware failure to achieve higher host availability. Multipathing is enabled by default in the agent ISO image, with an /etc/multipath.conf configuration. For details, see Modifying the DM Multipath configuration file.

Procedure

  1. Navigate to the Storage page of the wizard.
  2. Expand a host to display the associated storage disks.

  3. Select Installation disk from the Role list.

    Note

    Multipath devices are automatically discovered and listed in the host’s inventory. To assign a multipath Fibre Channel disk as the installation disk, choose a disk with Drive type set to Multipath, rather than to FC which indicates a single path.

  4. When all storage disks return to Ready status, proceed to the next step.

4.7.2. Disabling disk formatting

The Assisted Installer marks all bootable disks for formatting during the installation process by default, regardless of whether or not they have been defined as the installation disk. Formatting causes data loss.

You can choose to disable the formatting of a specific disk. Perform this with caution, as bootable disks can interfere with the installation process, mainly in terms of boot order.

You cannot disable formatting for the installation disk.

Procedure

  1. Navigate to the Storage page of the wizard.
  2. Expand a host to display the associated storage disks.
  3. Clear Format for a disk.
  4. When all storage disks return to Ready status, proceed to the next step.

Additional resources

4.8. Configuring networking

Before installing OpenShift Container Platform, you must configure the cluster network.

Procedure

  1. In the Networking step, select one of the following if it is not already selected for you:

    • Cluster-Managed Networking: Selecting cluster-managed networking means that the Assisted Installer will configure a standard network topology, including keepalived and Virtual Router Redundancy Protocol (VRRP) for managing the API and Ingress VIP addresses.

      Note
      • Currently, Cluster-Managed Networking is not supported on IBM Z® and IBM Power® in OpenShift Container Platform version 4.13.
      • Oracle Cloud Infrastructure (OCI) is available for OpenShift Container Platform 4.14 with a user-managed networking configuration only.
    • User-Managed Networking: Selecting user-managed networking deploys OpenShift Container Platform with a non-standard network topology. Select user-managed networking if you want to deploy with an external load balancer instead of keepalived and VRRP, or if you intend to deploy the cluster nodes across many distinct L2 network segments.

  2. For cluster-managed networking, configure the following settings:

    1. Select your Networking stack type:

      • IPv4: Select this type when your hosts are only using IPv4.
      • Dual-stack: You can select dual-stack when your hosts are using IPv4 together with IPv6.

    2. Define the Machine network. You can use the default network or select a subnet.

      Important

      For iSCSI boot volumes, the hosts connect over two machine networks: one designated for the OpenShift Container Platform installation and the other for iSCSI traffic. Ensure you select the OpenShift Container Platform network from the dropdown list. The iSCSI host IP address should not be on the machine network. Choosing the iSCSI network will result in an Insufficient status for the host in the Networking step.

    3. Define an API virtual IP. An API virtual IP provides an endpoint for all users to interact with, and configure the platform.
    4. Define an Ingress virtual IP. An Ingress virtual IP provides an endpoint for application traffic flowing from outside the cluster.

  3. Optional: Select Use advanced networking to configure the following advanced networking properties:

    • Cluster network CIDR: Define an IP address block to assign pod IP addresses.
    • Cluster network host prefix: Define a subnet prefix length to assign to each node.
    • Service network CIDR: Define an IP address block to assign service IP addresses.
  4. Optional: Select Host SSH Public Key for troubleshooting after installation to connect to hosts using a public SSH key for troubleshooting after installation.

Additional resources

4.9. Adding manifests and patches

You can upload custom manifests and patches for system manifests in the Assisted Installer web console. You can also replace and remove these files.

For information about adding and modifying custom manifests by using the Assisted Installer API, see Adding custom manifests with the API.

4.9.1. Preparing custom manifests and manifest patches

This section provides an overview of custom manifests and system manifest patches, including formatting considerations and the required naming conventions for uploading the files.

Follow these guidelines to ensure that the files you upload comply with the system requirements.

4.9.1.1. Custom manifests

A custom manifest is a JSON or YAML file that contains advanced configurations not currently supported in the Assisted Installer user interface. You can create a custom manifest or use one provided by a third party.

You can upload a custom manifest from your file system to either the openshift folder or the manifests folder. The number of custom manifest files permitted is unlimited.

You can upload only one file at a time. However, each uploaded YAML file can contain multiple custom manifests. Uploading a multi-document YAML manifest is faster than adding the YAML files individually.

For a file containing a single custom manifest, accepted file extensions include .yaml, .yml, or .json. For a file containing multiple custom manifests, accepted file types include .yaml or .yml.

Single custom manifest example

Copy to Clipboard Toggle word wrap 
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-openshift-machineconfig-master-kargs
spec:
  kernelArguments:
    - loglevel=7

Multiple custom manifest example

Copy to Clipboard Toggle word wrap 
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-openshift-machineconfig-master-kargs
spec:
  kernelArguments:
    - loglevel=7
---
apiVersion: machineconfiguration.openshift.io/v2
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 98-openshift-machineconfig-worker-kargs
spec:
  kernelArguments:
    - loglevel=5

Note

When you install OpenShift Container Platform on the Oracle Cloud Infrastructure (OCI) external platform, you must add the custom manifests provided by Oracle. For additional external partner integrations such as vSphere or Nutanix, this step is optional.

Additional resources

4.9.1.2. Patches for system manifests

A manifest patch file conforms to the syntax of a YAML patch. Its purpose is to modify a system manifest that is automatically created by the Assisted Installer during installation preparation. Manifest patches are used to adjust onfigurations, manage updates, or apply changes in a structured and automated way. This approach ensures consistency and helps avoid errors when altering complex YAML documents.

4.9.1.2.1. General YAML syntax for system manifest patches

The yaml-patch package is an implementation of JavaScript Object Notation (JSON) Patch, directly transposed to YAML. The general syntax of a system manifest YAML patch is the following:

Copy to Clipboard Toggle word wrap 
- op: <add | remove | replace | move | copy | test>
1 

  from: <source-path>
2 

  path: <target-path>
3 

  value: <any-yaml-structure>
4
1
See the JavaScript Object Notation (JSON) Patch for an explanation of each operation.
2
Only valid for move and copy operations.
3
Always mandatory.
4
Only valid for add, replace and test operations.
4.9.1.2.2. Naming conventions for system manifest patches

When creating a new patch for a system manifest, use the following naming convention: <file to be patched>.patch_<suffix>. The name itself ensures that the correct manifest is overwritten, and the suffix allows for the application of many patches to the same manifest.

For example, if the original file has the name 50-masters-chrony-configuration.yaml, then the new patch should be called 50-masters-chrony-configuration.yaml.patch_1_apply-chrony-dhcp or similar.

The following example outlines the steps for patching a system manifest, and shows how the naming convention is applied:

  1. The Assisted Installer automatically adds the following YAML file to the manifests of the cluster at the start of the installation.

    Directory: OpenShift
    Filename: 50-masters-chrony-configuration.yaml

    Copy to Clipboard Toggle word wrap 
    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 50-masters-chrony-configuration
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,CnBvb2wgMC5yaGVsLnBvb2wubnRwLm9yZyBpYnVyc3QKZHJpZnRmaWxlIC92YXIvbGliL2Nocm9ueS9kcmlmdAptYWtlc3RlcCAxLjAgMwpydGNzeW5jCmxvZ2RpciAvdmFyL2xvZy9jaHJvbnkKc2VydmVyIHN0YXRpYy4xOTAuMTExLjE2MS41LmNsaWVudHMueW91ci1zZXJ2ZXIuZGUgaWJ1cnN0CnNlcnZlciAyMDguNjcuNzIuNDMgaWJ1cnN0CnNlcnZlciBoMTM1LTEzNC0xMTEtMTIyLm1kc253aS5icm9hZGJhbmQuZHluYW1pYy50ZHMubmV0IGlidXJzdApzZXJ2ZXIgdGltZS5yaWNoaWVtY2ludG9zaC5jb20gaWJ1cnN0CnNlcnZlciBhcm0xLm1heGhvc3QuaW8gaWJ1cnN0CnNlcnZlciBzcGlkZXkucmVsbGltLmNvbSBpYnVyc3QKc2VydmVyIHVzLWVhc3QtMi5jbGVhcm5ldC5wdyBpYnVyc3QKc2VydmVyIDEwOC42MS43My4yNDMgaWJ1cnN0CnNlcnZlciBudHAxLm50cC0wMDEucHJvZC5pYWQyLmRjLnJlZGhhdC5jb20gaWJ1cnN0CnNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdApzZXJ2ZXIgaXAyMjkuaXAtNTEtODEtMjI2LnVzIGlidXJzdApzZXJ2ZXIgNjYuMjA1LjI0OS4yOCBpYnVyc3QKc2VydmVyIDEwLjExLjE2MC4yMzggaWJ1cnN0CnNlcnZlciBjLTczLTE5My02Mi01NC5oc2QxLndhLmNvbWNhc3QubmV0IGlidXJzdApzZXJ2ZXIgbnRwMi53aWt0ZWwuY29tIGlidXJzdA==
        mode: 420
        path: /etc/chrony.conf
        overwrite: true

  2. To patch this YAML file with different content, you must generate a new base64 representation of the content and create a patch file:

    1. Generate base64 file content for /etc/chrony.conf:

      Copy to Clipboard Toggle word wrap 
      $ cat << EOF | base64 --wrap 0of
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
logdir /var/log/chrony
sourcedir /run/chrony-dhcp
EOF
echo
ZHJpZnRmaWxlIC92YXIvbGliL2Nocm9ueS9kcmlmdAptYWtlc3RlcCAxLjAgMwpydGNzeW5jCmxvZ2RpciAvdmFyL2xvZy9jaHJvbnkKc291cmNlZGlyIC9ydW4vY2hyb255LWRoY3AK

    2. Create a patch file using this base64 string:

      Directory: OpenShift
      Filename: 50-masters-chrony-configuration.yaml.patch_1_apply-chrony-dhcp

      Copy to Clipboard Toggle word wrap 
       ---
- op: replace
  path: /spec/config/storage/files/0/contents
  value: data:text/plain;charset=utf-8;base64,ZHJpZnRmaWxlIC92YXIvbGliL2Nocm9ueS9kcmlmdAptYWtlc3RlcCAxLjAgMwpydGNzeW5jCmxvZ2RpciAvdmFyL2xvZy9jaHJvbnkKc291cmNlZGlyIC9ydW4vY2hyb255LWRoY3AK
  3. You then upload the patch file in the Assisted Installer web console. For details, see the following section.

4.9.2. Uploading custom manifests and manifest patches

When uploading a custom manifest or patch, enter the filename and select a destination folder. The filename must be unique across both folders; you cannot use the same file name in both folders.

Prerequisites

  • You have saved a custom manifest file to a local directory using an appropriate file name and extension.

Procedure

  1. On the Cluster details page of the wizard, select the Include custom manifests checkbox.

  2. On the Custom manifest page, in the folder field, select the Assisted Installer folder where you want to save the manifest or patch.

    Note

    You can upload a file to either the openShift or manifest folder. For a manifest patch, the system will look in both folders for the target file that it needs to patch.

  3. In the Filename field, enter a name for the manifest file, including the extension:

    • For custom manifests, examples include manifest1.json or multiple1.yaml.
    • For manifest patches, an example is 50-masters-chrony-configuration.yaml.patch_1_apply-chrony-dhcp.
  4. Under Content, click the Upload icon or Browse button to upload a file. Alternatively, drag the file into the Content field from your file system.
  5. To upload another file, click Add another manifest and repeat the process. This saves any previously uploaded files.
  6. Click Next to save all files and proceed to the Review and create page. Custom manifests displays a list of the uploaded custom manifests and patches.

4.9.3. Modifying custom manifests and manifest patches

You can rename uploaded custom manifest or patch files, and save custom manifest files to a different folder. Additionally, you can copy the contents of an existing file, or download it to the folder specified in your Chrome download settings.

It is not possible to edit the content of an uploaded manifest or patch file. Instead, you can overwrite the existing file.

Prerequisites

  • You have uploaded at least one custom manifest or patch file.

Procedure

  1. To change the location of a custom manifest file, select a different folder from the Folder list.
  2. To change the file name, type the new name for the manifest or patch in the File name field. Patch files should respect the patch naming conventions discussed earlier in this section.

  3. To overwrite a manifest or patch file, save a new file with the same file name in either the openshift or manifest folder.

    Note

    The system will automatically detect and replace the original file, regardless of which folder it is in.

  4. To download a manifest or patch to your file system, click the Download icon.
  5. To copy a manifest or patch, click the Copy to clipboard icon.
  6. To apply the changes, click either Add another manifest or Next.

4.9.4. Removing custom manifests and manifest patches

You can remove uploaded custom manifests or patches before installation in one of two ways:

  • Removing a single custom manifest or patch.
  • Removing all manifests and patches at the same time.
Warning

Once you have removed a manifest or patch file you cannot undo the action. The workaround is to upload the file again.

4.9.4.1. Removing all custom manifests and patches

You can remove all custom manifests and patches at the same time. This also hides the Custom manifest page.

Prerequisites

  • You have uploaded at least one custom manifest or patch file.

Procedure

  1. Browse to the Cluster details page of the wizard.
  2. Clear the Include custom manifests checkbox.
  3. In the Remove custom manifests dialog box, click Remove.

4.9.4.2. Removing a single custom manifest or patch

You can delete one file at a time. This option does not allow deletion of the last remaining manifest or patch.

Prerequisites

  • You have uploaded at least two custom manifest or patch files.

Procedure

  1. Browse to the Custom manifests page.
  2. Hover over the manifest name to display the Delete (minus) icon.
  3. Click the icon and then click Delete in the dialog box.

Additional resources

4.10. Preinstallation validations

The Assisted Installer ensures the cluster meets the prerequisites before installation, because it eliminates complex postinstallation troubleshooting, thereby saving significant amounts of time and effort. Before installing the cluster, ensure the cluster and each host pass preinstallation validation.

Additional resources

4.11. Installing the cluster

After you have completed the configuration and all the nodes are Ready, you can begin installation. The installation process takes a considerable amount of time, and you can monitor the installation from the Assisted Installer web console. Nodes will reboot during the installation, and they will initialize after installation.

Procedure

  1. Click Begin installation.
  2. Click the link in the Status column of the Host Inventory list to see the installation status of a particular host.

4.12. Completing the installation

After the cluster is installed and initialized, the Assisted Installer indicates that the installation is finished. The Assisted Installer provides the console URL, the kubeadmin username and password, and the kubeconfig file. Additionally, the Assisted Installer provides cluster details including the OpenShift Container Platform version, base domain, CPU architecture, API and Ingress IP addresses, and the cluster and service network IP addresses.

Prerequisites

  • You have installed the oc CLI tool.

Procedure

  1. Make a copy of the kubeadmin username and password.

  2. Download the kubeconfig file and copy it to the auth directory under your working directory:

    Copy to Clipboard Toggle word wrap 
    $ mkdir -p <working_directory>/auth
     Copy to Clipboard Toggle word wrap 
    $ cp kubeconfig <working_directory>/auth
    Note

    The kubeconfig file is available for download for 20 days after completing the installation.

  3. Add the kubeconfig file to your environment:

    Copy to Clipboard Toggle word wrap 
    $ export KUBECONFIG=<your working directory>/auth/kubeconfig

  4. Login with the oc CLI tool:

    Copy to Clipboard Toggle word wrap 
    $ oc login -u kubeadmin -p <password>

    Replace <password> with the password of the kubeadmin user.

  5. Click the web console URL or click Launch OpenShift Console to open the console.
  6. Enter the kubeadmin username and password. Follow the instructions in the OpenShift Container Platform console to configure an identity provider and configure alert receivers.
  7. Add a bookmark of the OpenShift Container Platform console.
  8. Complete any postinstallation platform integration steps.

Additional resources

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat, Inc.