Red Hat SummitChapter 9. Preinstallation validations
Before starting an installation, the Assisted Installer runs a series of checks to verify that the cluster configuration meets all requirements. You can review validation results and resolve any issues before proceeding with installation.
9.1. Overview of preinstallation validations
The Assisted Installer aims to make cluster installation as simple, efficient, and error-free as possible. It performs validation checks on the configuration and the gathered telemetry before starting an installation.
The Assisted Installer uses the information provided before installation, such as control plane topology, network configuration and hostnames. It will also use real time telemetry from the hosts you are attempting to install.
When a host boots the discovery ISO, an agent will start on the host. The agent will send information about the state of the host to the Assisted Installer.
The Assisted Installer uses all of this information to compute real-time preinstallation validations.
9.1.1. Host and cluster validations
The Assisted Installer performs validations at both the host and cluster levels.
- Host
- Host validations ensure that the configuration of a given host is valid for installation.
- Cluster
- Cluster validations ensure that the configuration of the whole cluster is valid for installation.
9.1.2. Blocking and non-blocking validations
All validations are either blocking or non-blocking to the installation.
- Blocking
- A blocking validation prevents progress of the installation, meaning that you need to resolve the issue and pass the blocking validation before you can proceed.
- Non-blocking
- A non-blocking validation is a warning and will tell you of things that might cause you a problem.
9.2. Host validations
You can retrieve and review validation results for each discovered host.
9.2.1. Getting host validations by using the REST API
Run the following procedure to retrieve host validation results by using the REST API.
If you use the web console, many of these validations will not show up by name. To get a list of validations consistent with the labels, use the following procedure.
Prerequisites
-
You have installed the
jqutility. - You have created an Infrastructure Environment by using the API or have created a cluster by using the web console.
- You have hosts booted with the discovery ISO
-
You have your Cluster ID exported in your shell as
CLUSTER_ID. -
You have credentials to use when accessing the API and have exported a token as
API_TOKENin your shell.
Procedure
Refresh the API token:
$ source refresh-tokenGet all validations for all hosts:
$ curl \ --silent \ --header "Authorization: Bearer $API_TOKEN" \ https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/hosts \ | jq -r .[].validations_info \ | jq 'map(.[])'Get non-passing validations for all hosts:
$ curl \ --silent \ --header "Authorization: Bearer $API_TOKEN" \ https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/hosts \ | jq -r .[].validations_info \ | jq 'map(.[]) | map(select(.status=="failure" or .status=="pending")) | select(length>0)'
9.2.2. Host validations in detail
The Assisted Installer performs the following host validations.
| Parameter | Validation type | Description |
|---|---|---|
|
| non-blocking | Checks that the host has recently communicated with the Assisted Installer. |
|
| non-blocking | Checks that the Assisted Installer received the inventory from the host. |
|
| non-blocking | Checks that the number of CPU cores meets the minimum requirements. |
|
| non-blocking | Checks that the amount of memory meets the minimum requirements. |
|
| non-blocking | Checks that at least one available disk meets the eligibility criteria. |
|
| blocking | Checks that the number of cores meets the minimum requirements for the host role. |
|
| blocking | Checks that the amount of memory meets the minimum requirements for the host role. |
|
| blocking | For Day 2 hosts, checks that the host can download ignition configuration from the Day 1 cluster. |
|
| blocking | The majority group is the largest full-mesh connectivity group on the cluster, where all members can communicate with all other members. [role="_abstract"] This validation checks that hosts in a multi-node, Day 1 cluster are in the majority group. |
|
| blocking | Checks that the platform is valid for the network settings. |
|
| non-blocking | Checks if an NTP server has been successfully used to synchronize time on the host. |
|
| non-blocking | Checks if container images have been successfully pulled from the image registry. |
|
| blocking | Checks that disk speed metrics from an earlier installation meet requirements, if they exist. |
|
| blocking | Checks that the average network latency between hosts in the cluster meets the requirements. |
|
| blocking | Checks that the network packet loss between hosts in the cluster meets the requirements. |
|
| blocking | Checks that the host has a default route configured. |
|
| blocking | For a multi node cluster with user managed networking. Checks that the host is able to resolve the API domain name for the cluster. |
|
| blocking | For a multi node cluster with user managed networking. Checks that the host is able to resolve the internal API domain name for the cluster. |
|
| blocking | For a multi node cluster with user managed networking. Checks that the host is able to resolve the internal apps domain name for the cluster. |
|
| non-blocking | Checks that the host is compatible with the cluster platform |
|
| blocking | Checks that the wildcard DNS *.<cluster_name>.<base_domain> is not configured, because this causes known problems for OpenShift |
|
| non-blocking | Checks that the type of host and disk encryption configured meet the requirements. |
|
| blocking | Checks that this host does not have any overlapping subnets. |
|
| blocking | Checks that the hostname is unique in the cluster. |
|
| blocking | Checks the validity of the hostname, meaning that it matches the general form of hostnames and is not forbidden.
|
|
| blocking | Checks that the host IP is in the address range of the machine CIDR. |
|
| blocking | Validates that the host meets the requirements of the Local Storage Operator. |
|
| blocking | Validates that the host meets the requirements of the OpenShift Data Foundation Operator.
|
|
| blocking | Validates that the host meets the requirements of Container Native Virtualization.
|
|
| blocking | Validates that the host meets the requirements of the Logical Volume Manager Storage Operator.
|
|
| non-blocking |
Verifies that each valid disk sets |
|
| blocking | Checks that the discovery agent version is compatible with the agent docker image version. |
|
| blocking | Checks that installation disk is not skipping disk formatting. |
|
| blocking | Checks that all disks marked to skip formatting are in the inventory. A disk ID can change on reboot, and this validation prevents issues caused by that. |
|
| blocking | Checks the connection of the installation media to the host. |
|
| non-blocking | Checks that the machine network definition exists for the cluster. |
|
| blocking | Checks that the platform is compatible with the network settings. Some platforms are only permitted when installing Single Node Openshift or when using User Managed Networking. |
|
| non-blocking | Checks the maximum transmission unit (MTU) of hosts and networking devices in the cluster environment to identify compatibility issues. For details, see Changing the MTU for the cluster network. |
9.3. Cluster validations
You can retrieve and review validation results for the cluster.
9.3.1. Getting cluster validations by using the REST API
Run the following procedure to retrieve cluster validation results by using the REST API.
If you use the web console, many of these validations will not show up by name. To obtain a list of validations consistent with the labels, use the following procedure.
Prerequisites
-
You have installed the
jqutility. - You have created an Infrastructure Environment by using the API or have created a cluster by using the web console.
-
You have your Cluster ID exported in your shell as
CLUSTER_ID. -
You have credentials to use when accessing the API and have exported a token as
API_TOKENin your shell.
Procedure
Refresh the API token:
$ source refresh-tokenGet all cluster validations:
$ curl \ --silent \ --header "Authorization: Bearer $API_TOKEN" \ https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID \ | jq -r .validations_info \ | jq 'map(.[])'Get non-passing cluster validations:
$ curl \ --silent \ --header "Authorization: Bearer $API_TOKEN" \ https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID \ | jq -r .validations_info \ | jq '. | map(.[] | select(.status=="failure" or .status=="pending")) | select(length>0)'
9.3.2. Cluster validations in detail
The Assisted Installer performs the following cluster validations.
| Parameter | Validation type | Description |
|---|---|---|
|
| non-blocking | Checks that the machine network definition exists for the cluster. |
|
| non-blocking | Checks that the cluster network definition exists for the cluster. |
|
| non-blocking | Checks that the service network definition exists for the cluster. |
|
| blocking | Checks that the defined networks do not overlap. |
|
| blocking | Checks that the defined networks share the same address families (valid address families are IPv4, IPv6) |
|
| blocking | Checks the cluster network prefix to ensure that it is valid and allows enough address space for all hosts. |
|
| blocking |
For a non user managed networking cluster. Checks that |
|
| non-blocking |
For a non user managed networking cluster. Checks that |
|
| blocking |
For a non user managed networking cluster. Checks if the |
|
| blocking |
For a non user managed networking cluster. Checks that |
|
| non-blocking |
For a non user managed networking cluster. Checks if the |
|
| blocking | Checks that all hosts in the cluster are in the "ready to install" status. |
|
| blocking [role="_abstract"] |
|
|
| non-blocking | Checks that the base DNS domain exists for the cluster. |
|
| non-blocking | Checks that the pull secret exists. Does not check that the pull secret is valid or authorized. |
|
| blocking | Checks that each of the host clocks are no more than 4 minutes out of sync with each other. |
|
| blocking | Validates that the cluster meets the requirements of the Local Storage Operator. |
|
| blocking | Validates that the cluster meets the requirements of the OpenShift Data Foundation Operator.
|
|
| blocking | Validates that the cluster meets the requirements of Container Native Virtualization.
|
|
| blocking | Validates that the cluster meets the requirements of the Logical Volume Manager Storage Operator.
|
|
| blocking | Checks the validity of the network type if it exists.
|
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}