Chapter 10. Preinstallation validations
10.1. Definition of preinstallation validations
The Assisted Installer aims to make cluster installation as simple, efficient, and error-free as possible. The Assisted Installer 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. All validations are either blocking or non-blocking to the installation.
10.2. Blocking and non-blocking validations
A blocking validation will prevent progress of the installation, meaning that you will need to resolve the issue and pass the blocking validation before you can proceed.
A non-blocking validation is a warning and will tell you of things that might cause you a problem.
10.3. Validation types
The Assisted Installer performs two types of validation:
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.
10.4. Host validations
10.4.1. Getting host validations 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.
Procedures
Refresh the API token:
$ source refresh-token
Get 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)'
10.4.2. Host validations in detail
| 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. 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 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 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. |
10.5. Cluster validations
10.5.1. Getting cluster validations 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.
Procedures
Refresh the API token:
$ source refresh-token
Get 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)'
10.5.2. Cluster validations in detail
| 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 | This validation only applies to multi-node clusters.
|
|
| 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 Red Hat 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 Operator.
|
|
| blocking | Checks the validity of the network type if it exists.
|
