From 04d113166ec9a15a0db73b035fa8dd35beae4d0e Mon Sep 17 00:00:00 2001 From: Sebastian Kopacz Date: Tue, 9 Jun 2026 10:22:02 -0400 Subject: [PATCH] OSDOCS-17038: Agent preparing docs CQA --- ...to-install-with-agent-based-installer.adoc | 32 +++++---- modules/agent-host-config.adoc | 3 +- modules/agent-host-roles.adoc | 1 + modules/agent-install-dns-none.adoc | 66 ++++++++--------- ...install-ipi-install-root-device-hints.adoc | 5 +- .../agent-install-load-balancing-none.adoc | 31 ++++---- modules/agent-install-networking.adoc | 71 +++++++++---------- modules/agent-install-requirements-none.adoc | 15 ++++ ...gent-install-sample-config-bond-sriov.adoc | 69 ++++++++++-------- ...ent-install-sample-config-bonds-vlans.adoc | 43 +++++------ ...installer-configuring-fips-compliance.adoc | 16 ++--- modules/agent-installer-fips-compliance.adoc | 2 + ...are-metal-agent-installer-config-yaml.adoc | 61 ++++++++-------- modules/understanding-agent-install.adoc | 35 +++++---- ...validations-before-agent-iso-creation.adoc | 18 ++--- 15 files changed, 254 insertions(+), 214 deletions(-) create mode 100644 modules/agent-install-requirements-none.adoc diff --git a/installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc b/installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc index 970525510cbb..795baaba8499 100644 --- a/installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc +++ b/installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc @@ -6,11 +6,10 @@ include::_attributes/common-attributes.adoc[] toc::[] -[id="about-the-agent-based-installer_{context}"] -== About the Agent-based Installer +[role="_abstract"] +The Agent-based Installer provides the flexibility to boot your on-premise servers in any way that you choose. It combines the ease of use of the Assisted Installation service with the ability to run offline, including in air-gapped environments. -The Agent-based installation method provides the flexibility to boot your on-premise servers in any way that you choose. It combines the ease of use of the Assisted Installation service with the ability to run offline, including in air-gapped environments. -Agent-based installation is a subcommand of the {product-title} installer. +The Agent-based Installer uses a subcommand of the {product-title} installation program. It generates a bootable ISO image containing all of the information required to deploy an {product-title} cluster, with an available release image. The configuration is in the same format as for the installer-provisioned infrastructure and user-provisioned infrastructure installation methods. @@ -56,6 +55,8 @@ include::modules/understanding-agent-install.adoc[leveloffset=+1] * xref:../../installing/overview/cluster-capabilities.adoc#cluster-capabilities[Cluster capabilities] +* link:https://access.redhat.com/articles/4207611[Deploying OpenShift 4.x on non-tested platforms using the bare metal install method (Red{nbsp}Hat Knowledgebase article)] + * xref:../../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#installation-requirements-platform-none_preparing-to-install-with-agent-based-installer[Requirements for a cluster using the platform "none" option] * xref:../installing_bare_metal/ipi/ipi-install-prerequisites.adoc#network-requirements-increase-mtu_ipi-install-prerequisites[Increase the network MTU] @@ -88,15 +89,8 @@ include::modules/agent-install-ipi-install-root-device-hints.adoc[leveloffset=+2 //About networking include::modules/agent-install-networking.adoc[leveloffset=+1] -[id="installation-requirements-platform-none_{context}"] -== Requirements for a cluster using the platform "none" option - -This section describes the requirements for an Agent-based {product-title} installation that is configured to use the platform `none` option. - -[IMPORTANT] -==== -Review the information in the link:https://access.redhat.com/articles/4207611[guidelines for deploying {product-title} on non-tested platforms] before you attempt to install an {product-title} cluster in virtualized or cloud environments. -==== +//Requirements for a cluster using the platform "none" option +include::modules/agent-install-requirements-none.adoc[leveloffset=+1] //Platform "none" DNS requirements include::modules/agent-install-dns-none.adoc[leveloffset=+2] @@ -104,6 +98,13 @@ include::modules/agent-install-dns-none.adoc[leveloffset=+2] //Platform "none" Load balancing requirements include::modules/agent-install-load-balancing-none.adoc[leveloffset=+2] +[role="_additional-resources"] +.Additional resources + +* xref:../../installing/overview/cluster-capabilities.adoc#cluster-capabilities[Cluster capabilities] + +* link:https://access.redhat.com/articles/4207611[Deploying OpenShift 4.x on non-tested platforms using the bare metal install method (Red{nbsp}Hat Knowledgebase article)] + //Example: Bonds and VLAN interface node network configuration include::modules/agent-install-sample-config-bonds-vlans.adoc[leveloffset=+1] @@ -121,8 +122,9 @@ include::modules/installation-bare-metal-agent-installer-config-yaml.adoc[levelo //Validation checks before agent ISO creation include::modules/validations-before-agent-iso-creation.adoc[leveloffset=+1] -[id="agent-based-installation-next-steps_{context}"] -== Next steps +[role="_additional-resources"] +[id="additional-resources_{context}"] +== Additional resources * xref:../../installing/installing_with_agent_based_installer/installing-with-agent-basic.adoc#installing-with-agent-basic[Installing a cluster] diff --git a/modules/agent-host-config.adoc b/modules/agent-host-config.adoc index d92c801e43c8..88c19bdfedb8 100644 --- a/modules/agent-host-config.adoc +++ b/modules/agent-host-config.adoc @@ -8,9 +8,10 @@ // Starting with whatever content I could find just to have something for feedback, but any additions or replacements are welcome. +[role="_abstract"] You can make additional configurations for each host on the cluster in the `agent-config.yaml` file, such as network configurations and root device hints. [IMPORTANT] ==== -For each host you configure, you must provide the MAC address of an interface on the host to specify which host you are configuring. +For each host you configure, you must specify which host you are configuring by providing the MAC address of an interface on the host. ==== \ No newline at end of file diff --git a/modules/agent-host-roles.adoc b/modules/agent-host-roles.adoc index e3c4d3b99446..988adc6136a3 100644 --- a/modules/agent-host-roles.adoc +++ b/modules/agent-host-roles.adoc @@ -6,6 +6,7 @@ [id="agent-host-roles_{context}"] = Host roles +[role="_abstract"] Each host in the cluster is assigned a role of either `master` or `worker`. You can define the role for each host in the `agent-config.yaml` file by using the `role` parameter. If you do not assign a role to the hosts, the roles will be assigned at random during installation. diff --git a/modules/agent-install-dns-none.adoc b/modules/agent-install-dns-none.adoc index 65cdf6425edb..d670cf7635f9 100644 --- a/modules/agent-install-dns-none.adoc +++ b/modules/agent-install-dns-none.adoc @@ -2,7 +2,10 @@ [id="agent-install-dns-none_{context}"] = Platform "none" DNS requirements -In {product-title} deployments, DNS name resolution is required for the following components: +[role="_abstract"] +In {product-title} deployments, DNS name resolution is required for several components. + +The following components need DNS name resolution: * The Kubernetes API * The {product-title} application wildcard @@ -75,13 +78,11 @@ This section provides A and PTR record configuration samples that meet the DNS r In the examples, the cluster name is `ocp4` and the base domain is `example.com`. -.Example DNS A record configuration for a platform "none" cluster +Example DNS A record configuration for a platform "none" cluster:: The following example is a BIND zone file that shows sample A records for name resolution in a cluster using the platform `none` option. .Sample DNS zone database -[%collapsible] -==== [source,text] ---- $TTL 1W @@ -101,41 +102,39 @@ smtp.example.com. IN A 192.168.1.5 helper.example.com. IN A 192.168.1.5 helper.ocp4.example.com. IN A 192.168.1.5 ; -api.ocp4.example.com. IN A 192.168.1.5 <1> -api-int.ocp4.example.com. IN A 192.168.1.5 <2> +api.ocp4.example.com. IN A 192.168.1.5 +api-int.ocp4.example.com. IN A 192.168.1.5 ; -*.apps.ocp4.example.com. IN A 192.168.1.5 <3> +*.apps.ocp4.example.com. IN A 192.168.1.5 ; -master0.ocp4.example.com. IN A 192.168.1.97 <4> -master1.ocp4.example.com. IN A 192.168.1.98 <4> -master2.ocp4.example.com. IN A 192.168.1.99 <4> +master0.ocp4.example.com. IN A 192.168.1.97 +master1.ocp4.example.com. IN A 192.168.1.98 +master2.ocp4.example.com. IN A 192.168.1.99 ; -worker0.ocp4.example.com. IN A 192.168.1.11 <5> -worker1.ocp4.example.com. IN A 192.168.1.7 <5> +worker0.ocp4.example.com. IN A 192.168.1.11 +worker1.ocp4.example.com. IN A 192.168.1.7 ; ;EOF ---- +where: -<1> Provides name resolution for the Kubernetes API. The record refers to the IP address of the API load balancer. -<2> Provides name resolution for the Kubernetes API. The record refers to the IP address of the API load balancer and is used for internal cluster communications. -<3> Provides name resolution for the wildcard routes. The record refers to the IP address of the application ingress load balancer. The application ingress load balancer targets the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default. +`api.ocp4.example.com.`:: Provides name resolution for the Kubernetes API. The record refers to the IP address of the API load balancer. +`api-int.ocp4.example.com.`:: Provides name resolution for the Kubernetes API. The record refers to the IP address of the API load balancer and is used for internal cluster communications. +`*.apps.ocp4.example.com.`:: Provides name resolution for the wildcard routes. The record refers to the IP address of the application ingress load balancer. The application ingress load balancer targets the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default. + [NOTE] ===== In the example, the same load balancer is used for the Kubernetes API and application ingress traffic. In production scenarios, you can deploy the API and application ingress load balancers separately so that you can scale the load balancer infrastructure for each in isolation. ===== + -<4> Provides name resolution for the control plane machines. -<5> Provides name resolution for the compute machines. -==== +`master0.ocp4.example.com.`-`master2.ocp4.example.com.`:: Provides name resolution for the control plane machines. +`worker0.ocp4.example.com.`-`worker1.ocp4.example.com.`:: Provides name resolution for the compute machines. -.Example DNS PTR record configuration for a platform "none" cluster +Example DNS PTR record configuration for a platform "none" cluster:: The following example BIND zone file shows sample PTR records for reverse name resolution in a cluster using the platform `none` option. .Sample DNS zone database for reverse records -[%collapsible] -==== [source,text] ---- $TTL 1W @@ -147,24 +146,25 @@ $TTL 1W 1W ) ; minimum (1 week) IN NS ns1.example.com. ; -5.1.168.192.in-addr.arpa. IN PTR api.ocp4.example.com. <1> -5.1.168.192.in-addr.arpa. IN PTR api-int.ocp4.example.com. <2> +5.1.168.192.in-addr.arpa. IN PTR api.ocp4.example.com. +5.1.168.192.in-addr.arpa. IN PTR api-int.ocp4.example.com. ; -97.1.168.192.in-addr.arpa. IN PTR master0.ocp4.example.com. <3> -98.1.168.192.in-addr.arpa. IN PTR master1.ocp4.example.com. <3> -99.1.168.192.in-addr.arpa. IN PTR master2.ocp4.example.com. <3> +97.1.168.192.in-addr.arpa. IN PTR master0.ocp4.example.com. +98.1.168.192.in-addr.arpa. IN PTR master1.ocp4.example.com. +99.1.168.192.in-addr.arpa. IN PTR master2.ocp4.example.com. ; -11.1.168.192.in-addr.arpa. IN PTR worker0.ocp4.example.com. <4> -7.1.168.192.in-addr.arpa. IN PTR worker1.ocp4.example.com. <4> +11.1.168.192.in-addr.arpa. IN PTR worker0.ocp4.example.com. +7.1.168.192.in-addr.arpa. IN PTR worker1.ocp4.example.com. ; ;EOF ---- +where: + +`api.ocp4.example.com.`:: Provides reverse DNS resolution for the Kubernetes API. The PTR record refers to the record name of the API load balancer. +`api-int.ocp4.example.com.`:: Provides reverse DNS resolution for the Kubernetes API. The PTR record refers to the record name of the API load balancer and is used for internal cluster communications. +`master0.ocp4.example.com.`-`master2.ocp4.example.com.`:: Provides reverse DNS resolution for the control plane machines. +`worker0.ocp4.example.com.`-`worker1.ocp4.example.com.`:: Provides reverse DNS resolution for the compute machines. -<1> Provides reverse DNS resolution for the Kubernetes API. The PTR record refers to the record name of the API load balancer. -<2> Provides reverse DNS resolution for the Kubernetes API. The PTR record refers to the record name of the API load balancer and is used for internal cluster communications. -<3> Provides reverse DNS resolution for the control plane machines. -<4> Provides reverse DNS resolution for the compute machines. -==== [NOTE] ==== diff --git a/modules/agent-install-ipi-install-root-device-hints.adoc b/modules/agent-install-ipi-install-root-device-hints.adoc index ab0568f3fc9b..b768ca910b18 100644 --- a/modules/agent-install-ipi-install-root-device-hints.adoc +++ b/modules/agent-install-ipi-install-root-device-hints.adoc @@ -6,7 +6,10 @@ [id='root-device-hints_{context}'] = About root device hints -The `rootDeviceHints` parameter enables the installer to provision the {op-system-first} image to a particular device. The installer examines the devices in the order it discovers them, and compares the discovered values with the hint values. The installer uses the first discovered device that matches the hint value. The configuration can combine multiple hints, but a device must match all hints for the installer to select it. +[role="_abstract"] +The `rootDeviceHints` parameter enables the installation program to provision the {op-system-first} image to a particular device. + +The installation program examines the devices in the order it discovers them, and compares the discovered values with the hint values. The installation program uses the first discovered device that matches the hint value. The configuration can combine multiple hints, but a device must match all hints for the installation program to select it. .Subfields diff --git a/modules/agent-install-load-balancing-none.adoc b/modules/agent-install-load-balancing-none.adoc index 5ce4d07ff64f..d32c90c7fe4b 100644 --- a/modules/agent-install-load-balancing-none.adoc +++ b/modules/agent-install-load-balancing-none.adoc @@ -2,17 +2,14 @@ [id="agent-install-load-balancing-none_{context}"] = Platform "none" Load balancing requirements - +[role="_abstract"] Before you install {product-title}, you must provision the API and application Ingress load balancing infrastructure. In production scenarios, you can deploy the API and application Ingress load balancers separately so that you can scale the load balancer infrastructure for each in isolation. [NOTE] ==== -These requirements do not apply to single-node OpenShift clusters using the platform `none` option. -==== +* These requirements do not apply to {sno} clusters using the platform `none` option. -[NOTE] -==== -If you want to deploy the API and application Ingress load balancers with a {op-system-base-full} instance, you must purchase the {op-system-base} subscription separately. +* If you want to deploy the API and application Ingress load balancers with a {op-system-base-full} instance, you must purchase the {op-system-base} subscription separately. ==== The load balancing infrastructure must meet the following requirements: @@ -123,8 +120,6 @@ If you are using HAProxy as a load balancer and SELinux is set to `enforcing`, y ==== .Sample API and application Ingress load balancer configuration -[%collapsible] -==== [source,text] ---- global @@ -147,25 +142,25 @@ defaults timeout http-keep-alive 10s timeout check 10s maxconn 3000 -listen api-server-6443 <1> +listen api-server-6443 bind *:6443 mode tcp server master0 master0.ocp4.example.com:6443 check inter 1s server master1 master1.ocp4.example.com:6443 check inter 1s server master2 master2.ocp4.example.com:6443 check inter 1s -listen machine-config-server-22623 <2> +listen machine-config-server-22623 bind *:22623 mode tcp server master0 master0.ocp4.example.com:22623 check inter 1s server master1 master1.ocp4.example.com:22623 check inter 1s server master2 master2.ocp4.example.com:22623 check inter 1s -listen ingress-router-443 <3> +listen ingress-router-443 bind *:443 mode tcp balance source server worker0 worker0.ocp4.example.com:443 check inter 1s server worker1 worker1.ocp4.example.com:443 check inter 1s -listen ingress-router-80 <4> +listen ingress-router-80 bind *:80 mode tcp balance source @@ -173,17 +168,17 @@ listen ingress-router-80 <4> server worker1 worker1.ocp4.example.com:80 check inter 1s ---- -<1> Port `6443` handles the Kubernetes API traffic and points to the control plane machines. You must configure health checks on this port to ensure that the API server is available before routing traffic. -<2> Port `22623` handles the machine config server traffic and points to the control plane machines. -<3> Port `443` handles the HTTPS traffic and points to the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default. -<4> Port `80` handles the HTTP traffic and points to the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default. +* Port `6443` handles the Kubernetes API traffic and points to the control plane machines. You must configure health checks on this port to ensure that the API server is available before routing traffic. +* Port `22623` handles the machine config server traffic and points to the control plane machines. +* Port `443` handles the HTTPS traffic and points to the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default. +* Port `80` handles the HTTP traffic and points to the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default. + [NOTE] -===== +==== If you are deploying a compact three-node cluster with zero compute nodes, the Ingress Controller pods run on the control plane nodes. In three-node cluster deployments, you must configure your application Ingress load balancer to route HTTP and HTTPS traffic to the control plane nodes. -===== ==== + [TIP] ==== If you are using HAProxy as a load balancer, you can check that the `haproxy` process is listening on ports `6443`, `22623`, `443`, and `80` by running `netstat -nltupe` on the HAProxy node. diff --git a/modules/agent-install-networking.adoc b/modules/agent-install-networking.adoc index cdc3d420f33a..67d5f579945e 100644 --- a/modules/agent-install-networking.adoc +++ b/modules/agent-install-networking.adoc @@ -6,7 +6,9 @@ [id="agent-install-networking_{context}"] = About networking +[role="_abstract"] The *rendezvous IP* must be known at the time of generating the agent ISO, so that during the initial boot all the hosts can check in to the assisted service. + If the IP addresses are assigned using a Dynamic Host Configuration Protocol (DHCP) server, then the `rendezvousIP` field must be set to an IP address of one of the hosts that will become part of the deployed control plane. In an environment without a DHCP server, you can define IP addresses statically. @@ -21,9 +23,7 @@ Do not set the `network.machineNetwork.cidr` parameter to include this address r [id="agent-install-networking-DHCP_{context}"] == DHCP -.Preferred method: `install-config.yaml` and `agent-config.yaml` - -You must specify the value for the `rendezvousIP` field. The `networkConfig` fields can be left blank: +When using Dynamic Host Configuration Protocol (DHCP), you must specify the value for the `rendezvousIP` field in the `agent-config.yaml` file, and the `networkConfig` fields can be left blank: .Sample agent-config.yaml.file @@ -33,18 +33,19 @@ apiVersion: v1alpha1 kind: AgentConfig metadata: name: sno-cluster -rendezvousIP: 192.168.111.80 <1> +rendezvousIP: 192.168.111.80 ---- -<1> The IP address for the rendezvous host. +where: + +`rendezvousIP`:: Specifies the IP address for the rendezvous host. [id="agent-install-networking-static_{context}"] == Static networking -.. Preferred method: `install-config.yaml` and `agent-config.yaml` +When using static networking with the preferred `install-config.yaml` and `agent-config.yaml` files, you can specify the value for the `rendezvousIP` field in the `agent-config.yaml` file or allow the installation program to choose a static IP address from the `networkConfig` fields. + -+ .Sample agent-config.yaml.file -+ [source,yaml] ---- cat > agent-config.yaml << EOF @@ -52,12 +53,12 @@ apiVersion: v1alpha1 kind: AgentConfig metadata: name: sno-cluster -rendezvousIP: 192.168.111.80 <1> +rendezvousIP: 192.168.111.80 hosts: - hostname: master-0 interfaces: - name: eno1 - macAddress: 00:ef:44:21:e6:a5 <2> + macAddress: 00:ef:44:21:e6:a5 networkConfig: interfaces: - name: eno1 @@ -67,35 +68,33 @@ hosts: ipv4: enabled: true address: - - ip: 192.168.111.80 <3> - prefix-length: 23 <4> + - ip: 192.168.111.80 + prefix-length: 23 dhcp: false dns-resolver: config: server: - - 192.168.111.1 <5> + - 192.168.111.1 routes: config: - destination: 0.0.0.0/0 - next-hop-address: 192.168.111.1 <6> + next-hop-address: 192.168.111.1 next-hop-interface: eno1 table-id: 254 EOF ---- -<1> If a value is not specified for the `rendezvousIP` field, one address will be chosen from the static IP addresses specified in the `networkConfig` fields. -<2> The MAC address of an interface on the host, used to determine which host to apply the configuration to. -<3> The static IP address of the target bare metal host. -<4> The static IP address’s subnet prefix for the target bare metal host. -<5> The DNS server for the target bare metal host. -<6> Next hop address for the node traffic. This must be in the same subnet as the IP address set for the specified interface. +where: -+ -.. Optional method: {ztp} manifests +`rendezvousIP`:: Specifies the IP address for the rendezvous host. If a value is not specified for the `rendezvousIP` field, one address will be chosen from the static IP addresses specified in the `networkConfig` fields. +`hosts.interfaces.macAddress`:: Specifies the MAC address of an interface on the host, used to determine which host to apply the configuration to. +`ipv4.address.ip`:: Specifies the static IP address of the target bare-metal host. +`ipv4.address.prefix-length`:: Specifies the static IP address's subnet prefix for the target bare-metal host. +`dns-resolver.config.server`:: Specifies the DNS server for the target bare-metal host. +`routes.config.next-hop-address`:: Specifies the next-hop address for the node traffic. This must be in the same subnet as the IP address set for the specified interface. -+ -The optional method of the {ztp} custom resources comprises 6 custom resources; you can configure static IPs in the `nmstateconfig.yaml` file. +When using static networking with the optional method of {ztp} custom resources, which comprises 6 custom resources, you can configure static IPs in the `nmstateconfig.yaml` file. The rendezvous IP is chosen from the static IP addresses specified in the `config` fields. -+ +.Sample nmstateconfig.yaml file [source,yaml] ---- apiVersion: agent-install.openshift.io/v1beta1 @@ -115,27 +114,27 @@ spec: ipv4: enabled: true address: - - ip: 192.168.122.2 <1> - prefix-length: 23 <2> + - ip: 192.168.122.2 + prefix-length: 23 dhcp: false dns-resolver: config: server: - - 192.168.122.1 <3> + - 192.168.122.1 routes: config: - destination: 0.0.0.0/0 - next-hop-address: 192.168.122.1 <4> + next-hop-address: 192.168.122.1 next-hop-interface: eth0 table-id: 254 interfaces: - name: eth0 - macAddress: 52:54:01:aa:aa:a1 <5> + macAddress: 52:54:01:aa:aa:a1 ---- -<1> The static IP address of the target bare metal host. -<2> The static IP address’s subnet prefix for the target bare metal host. -<3> The DNS server for the target bare metal host. -<4> Next hop address for the node traffic. This must be in the same subnet as the IP address set for the specified interface. -<5> The MAC address of an interface on the host, used to determine which host to apply the configuration to. +where: -The rendezvous IP is chosen from the static IP addresses specified in the `config` fields. +`ipv4.address.ip`:: Specifies the static IP address of the target bare-metal host. +`ipv4.address.prefix-length`:: Specifies the static IP address's subnet prefix for the target bare-metal host. +`dns-resolver.config.server`:: Specifies the DNS server for the target bare-metal host. +`routes.config.next-hop-address`:: Specifies the next-hop address for the node traffic. This must be in the same subnet as the IP address set for the specified interface. +`spec.interfaces.macAddress`:: Specifies the MAC address of an interface on the host, used to determine which host to apply the configuration to. diff --git a/modules/agent-install-requirements-none.adoc b/modules/agent-install-requirements-none.adoc new file mode 100644 index 000000000000..c043191e284d --- /dev/null +++ b/modules/agent-install-requirements-none.adoc @@ -0,0 +1,15 @@ +// Module included in the following assemblies: +// +// * installing/installing-with-agent-based-installer/preparing-to-install-with-agent-based-installer.adoc + +:_mod-docs-content-type: CONCEPT +[id="installation-requirements-platform-none_{context}"] += Requirements for a cluster using the platform "none" option + +[role="_abstract"] +There are additional requirements when installing a cluster using the platform "none" option with the Agent-based Installer. + +[IMPORTANT] +==== +See "Deploying OpenShift 4.x on non-tested platforms using the bare metal install method" before you attempt to install an {product-title} cluster in virtualized or cloud environments. +==== \ No newline at end of file diff --git a/modules/agent-install-sample-config-bond-sriov.adoc b/modules/agent-install-sample-config-bond-sriov.adoc index d0a2cbbb2446..6e35845438db 100644 --- a/modules/agent-install-sample-config-bond-sriov.adoc +++ b/modules/agent-install-sample-config-bond-sriov.adoc @@ -6,6 +6,9 @@ [id="agent-install-sample-config-bond-sriov_{context}"] = Example: Bonds and SR-IOV dual-NIC node network configuration +[role="_abstract"] +See example manifest files to better understand configuration options for deploying your cluster. + The following `agent-config.yaml` file is an example of a manifest for dual port network interface controller (NIC) with a bond and SR-IOV interfaces: [source,yaml] @@ -20,25 +23,25 @@ hosts: macAddress: 0c:42:a1:55:f3:06 - name: eno2 macAddress: 0c:42:a1:55:f3:07 - networkConfig: <1> - interfaces: <2> - - name: eno1 <3> - type: ethernet <4> + networkConfig: + interfaces: + - name: eno1 + type: ethernet state: up mac-address: 0c:42:a1:55:f3:06 ipv4: enabled: true - dhcp: false <5> + dhcp: false ethernet: sr-iov: - total-vfs: 2 <6> + total-vfs: 2 ipv6: enabled: false - name: sriov:eno1:0 type: ethernet - state: up <7> + state: up ipv4: - enabled: false <8> + enabled: false ipv6: enabled: false dhcp: false @@ -69,18 +72,18 @@ hosts: - name: bond0 type: bond state: up - min-tx-rate: 100 <9> - max-tx-rate: 200 <10> + min-tx-rate: 100 + max-tx-rate: 200 link-aggregation: - mode: active-backup <11> + mode: active-backup options: - primary: sriov:eno1:0 <12> + primary: sriov:eno1:0 port: - sriov:eno1:0 - sriov:eno2:0 ipv4: address: - - ip: 10.19.16.57 <13> + - ip: 10.19.16.57 prefix-length: 23 dhcp: false enabled: true @@ -95,27 +98,33 @@ hosts: config: - destination: 0.0.0.0/0 next-hop-address: 10.19.17.254 - next-hop-interface: bond0 <14> + next-hop-interface: bond0 table-id: 254 ---- -<1> The `networkConfig` field includes information about the network configuration of the host, with subfields including `interfaces`,`dns-resolver`, and `routes`. -<2> The `interfaces` field is an array of network interfaces defined for the host. -<3> The name of the interface. +where: + +`networkConfig`:: Specifies information about the network configuration of the host, with subfields including `interfaces`,`dns-resolver`, and `routes`. +`networkConfig.interfaces`:: Specifies an array of network interfaces defined for the host. +`networkConfig.interfaces.name`:: Specifies the name of the interface. + [NOTE] ==== This value does not need to match the device name. ==== -<4> The type of interface. This example creates an ethernet interface. -<5> Set this to `false` to disable DHCP for the physical function (PF) if it is not strictly required. -<6> Set this to the number of SR-IOV virtual functions (VFs) to instantiate. -<7> Set this to `up`. -<8> Set this to `false` to disable IPv4 addressing for the VF attached to the bond. -<9> Sets a minimum transmission rate, in Mbps, for the VF. This sample value sets a rate of 100 Mbps. - * This value must be less than or equal to the maximum transmission rate. - * Intel NICs do not support the `min-tx-rate` parameter. For more information, see link:https://bugzilla.redhat.com/show_bug.cgi?id=1772847[*BZ#1772847*]. -<10> Sets a maximum transmission rate, in Mbps, for the VF. This sample value sets a rate of 200 Mbps. -<11> Sets the needed bond mode. -<12> Sets the preferred port of the bonding interface. The primary device is the first of the bonding interfaces to be used and is not abandoned unless it fails. This setting is particularly useful when one NIC in the bonding interface is faster and, therefore, able to handle a bigger load. This setting is only valid when the bonding interface is in `active-backup` mode (mode 1). -<13> Sets a static IP address for the bond interface. This is the node IP address. -<14> Sets `bond0` as the gateway for the default route. \ No newline at end of file +`networkConfig.interfaces.type`:: Specifies the type of interface. This example creates an ethernet interface. +`networkConfig.interfaces.ipv4.dhcp`:: Specifies DHCP enablement. +Set this to `false` to disable DHCP for the physical function (PF) if it is not strictly required. +`ethernet.sr-iov.total-vfs`:: Specifies the number of SR-IOV virtual functions (VFs) to instantiate. +`networkConfig.interfaces.state`:: Specifies the value of `networkConfig.interfaces.state`. Set this parameter to `up`. +`networkConfig.interfaces.ipv4.enabled`:: Specifies the enablement of IPv4 addressing for the VF attached to the bond. Set this to `false` to disable. +`networkConfig.interfaces.min-tx-rate`:: Specifies a minimum transmission rate, in Mbps, for the VF. This sample value sets a rate of 100 Mbps. This value must be less than or equal to the maximum transmission rate. ++ +[NOTE] +==== +Intel NICs do not support the `min-tx-rate` parameter. For more information, see link:https://bugzilla.redhat.com/show_bug.cgi?id=1772847[*BZ#1772847*]. +==== +`networkConfig.interfaces.max-tx-rate`:: Specifies a maximum transmission rate, in Mbps, for the VF. This sample value sets a rate of 200 Mbps. +`link-aggregation.mode`:: Specifies the needed bond mode. +`link-aggregation.options.primary`:: Specifies the preferred port of the bonding interface. The primary device is the first of the bonding interfaces to be used and is not abandoned unless it fails. This setting is particularly useful when one NIC in the bonding interface is faster and, therefore, able to handle a bigger load. This setting is only valid when the bonding interface is in `active-backup` mode (mode 1). +`ipv4.address.ip`:: Specifies a static IP address for the bond interface. This is the node IP address. +`routes.config.next-hop-interface`:: Specifies `bond0` as the gateway for the default route. \ No newline at end of file diff --git a/modules/agent-install-sample-config-bonds-vlans.adoc b/modules/agent-install-sample-config-bonds-vlans.adoc index 40c139c39c93..3db8c957f4f4 100644 --- a/modules/agent-install-sample-config-bonds-vlans.adoc +++ b/modules/agent-install-sample-config-bonds-vlans.adoc @@ -6,7 +6,10 @@ [id="agent-install-sample-config-bonds-vlans_{context}"] = Example: Bonds and VLAN interface node network configuration -The following `agent-config.yaml` file is an example of a manifest for bond and VLAN interfaces. +[role="_abstract"] +See example manifest files to better understand configuration options for deploying your cluster. + +The following `agent-config.yaml` file is an example of a manifest for bond and VLAN interfaces: [source,yaml] ---- @@ -23,8 +26,8 @@ The following `agent-config.yaml` file is an example of a manifest for bond and macAddress: 00:21:50:90:c0:20 networkConfig: interfaces: - - name: bond0.300 <1> - type: vlan <2> + - name: bond0.300 + type: vlan state: up vlan: base-iface: bond0 @@ -35,22 +38,22 @@ The following `agent-config.yaml` file is an example of a manifest for bond and - ip: 10.10.10.14 prefix-length: 24 dhcp: false - - name: bond0 <1> - type: bond <3> + - name: bond0 + type: bond state: up - mac-address: 00:21:50:90:c0:10 <4> + mac-address: 00:21:50:90:c0:10 ipv4: enabled: false ipv6: enabled: false link-aggregation: - mode: active-backup <5> + mode: active-backup options: - miimon: "150" <6> + miimon: "150" port: - enp0s4 - enp0s5 - dns-resolver: <7> + dns-resolver: config: server: - 10.10.10.11 @@ -58,21 +61,21 @@ The following `agent-config.yaml` file is an example of a manifest for bond and routes: config: - destination: 0.0.0.0/0 - next-hop-address: 10.10.10.10 <8> - next-hop-interface: bond0.300 <9> + next-hop-address: 10.10.10.10 + next-hop-interface: bond0.300 table-id: 254 ---- -<1> Name of the interface. +where: + +`networkConfig.interfaces.name`:: Specifies the name of the interface. + [NOTE] ==== This value does not need to match the device name. ==== -<2> The type of interface. This example creates a VLAN. -<3> The type of interface. This example creates a bond. -<4> The mac address of the interface. -<5> The `mode` attribute specifies the bonding mode. -<6> Specifies the MII link monitoring frequency in milliseconds. This example inspects the bond link every 150 milliseconds. -<7> Optional: Specifies the search and server settings for the DNS server. -<8> Next hop address for the node traffic. This must be in the same subnet as the IP address set for the specified interface. -<9> Next hop interface for the node traffic. +`networkConfig.interfaces.type`:: Specifies the type of interface. Specifying `vlan` creates a VLAN and specifying `bond` creates a bond. +`link-aggregation.mode`:: Specifies the bonding mode. +`link-aggregation.options.mode`:: Specifies the MII link monitoring frequency in milliseconds. This example inspects the bond link every 150 milliseconds. +`dns-resolver`:: Specifies the search and server settings for the DNS server. This configuration is optional. +`routes.config.next-hop-address`:: Specifies the next hop address for the node traffic. This must be in the same subnet as the IP address set for the specified interface. +`routes.config.next-hop-interface`:: Specifies the next hop interface for the node traffic. diff --git a/modules/agent-installer-configuring-fips-compliance.adoc b/modules/agent-installer-configuring-fips-compliance.adoc index 4cf77ad5499b..772718d72489 100644 --- a/modules/agent-installer-configuring-fips-compliance.adoc +++ b/modules/agent-installer-configuring-fips-compliance.adoc @@ -3,11 +3,12 @@ // * installing/installing_with_agent_bases_installer/preparing-to-install-with-agent-based-installer.adoc -:_mod-docs-content-type: PROCEDURE +:_mod-docs-content-type: CONCEPT [id="agent-installer-configuring-fips-compliance_{context}"] -= Configuring FIPS through the Agent-based Installer += Configure FIPS through the Agent-based Installer +[role="_abstract"] During a cluster deployment, the Federal Information Processing Standards (FIPS) change is applied when the Red Hat Enterprise Linux CoreOS (RHCOS) machines are deployed in your cluster. For Red Hat Enterprise Linux (RHEL) machines, you must enable FIPS mode when you install the operating system on the machines that you plan to use as worker machines. [IMPORTANT] @@ -15,10 +16,10 @@ During a cluster deployment, the Federal Information Processing Standards (FIPS) {product-title} requires the use of a FIPS-capable installation binary to install a cluster in FIPS mode. ==== -You can enable FIPS mode through the preferred method of `install-config.yaml` and `agent-config.yaml`: +You can enable FIPS mode through the preferred method of `install-config.yaml` and `agent-config.yaml` files: + +You must set value of the `fips` field to `true` in the `install-config.yaml` file: -. You must set value of the `fips` field to `true` in the `install-config.yaml` file: -+ .Sample install-config.yaml.file [source,yaml] @@ -29,15 +30,14 @@ metadata: name: sno-cluster fips: true ---- -+ + [IMPORTANT] ==== To enable FIPS mode on {ibm-z-name} clusters, you must also enable FIPS in either the `.parm` file or using `virt-install` as outlined in the procedures for manually adding {ibm-z-name} agents. ==== -. Optional: If you are using the {ztp} manifests, you must set the value of `fips` as `true` in the `agent-install.openshift.io/install-config-overrides` field in the `agent-cluster-install.yaml` file: +If you are using the optional {ztp} manifests, you must set the value of `fips` as `true` in the `agent-install.openshift.io/install-config-overrides` field in the `agent-cluster-install.yaml` file: -+ .Sample agent-cluster-install.yaml file [source,yaml] ---- diff --git a/modules/agent-installer-fips-compliance.adoc b/modules/agent-installer-fips-compliance.adoc index bebfbabc21e6..e91dfbf00d36 100644 --- a/modules/agent-installer-fips-compliance.adoc +++ b/modules/agent-installer-fips-compliance.adoc @@ -7,7 +7,9 @@ [id="agent-installer-fips-compliance_{context}"] = About FIPS compliance +[role="_abstract"] For many {product-title} customers, regulatory readiness, or compliance, on some level is required before any systems can be put into production. That regulatory readiness can be imposed by national standards, industry standards or the organization's corporate governance framework. + Federal Information Processing Standards (FIPS) compliance is one of the most critical components required in highly secure environments to ensure that only supported cryptographic technologies are allowed on nodes. include::snippets/fips-snippet.adoc[] diff --git a/modules/installation-bare-metal-agent-installer-config-yaml.adoc b/modules/installation-bare-metal-agent-installer-config-yaml.adoc index f12b984531c2..df6e0d1706ca 100644 --- a/modules/installation-bare-metal-agent-installer-config-yaml.adoc +++ b/modules/installation-bare-metal-agent-installer-config-yaml.adoc @@ -7,60 +7,62 @@ [id="installation-bare-metal-agent-installer-config-yaml_{context}"] = Sample install-config.yaml file for bare metal +[role="_abstract"] You can customize the `install-config.yaml` file to specify more details about your {product-title} cluster's platform or modify the values of the required parameters. +.Sample install-config.yaml file for bare metal [source,yaml] ---- apiVersion: v1 -baseDomain: example.com <1> -compute: <2> +baseDomain: example.com +compute: - name: worker - replicas: 0 <3> + replicas: 0 architecture: amd64 -controlPlane: <2> +controlPlane: name: master - replicas: 1 <4> + replicas: 1 architecture: amd64 metadata: - name: sno-cluster <5> + name: sno-cluster networking: clusterNetwork: - - cidr: 10.128.0.0/14 <6> - hostPrefix: 23 <7> + - cidr: 10.128.0.0/14 + hostPrefix: 23 machineNetwork: - cidr: 192.168.0.0/16 - networkType: OVNKubernetes <8> - serviceNetwork: <9> + networkType: OVNKubernetes + serviceNetwork: - 172.30.0.0/16 platform: - none: {} <10> -fips: false <11> -pullSecret: '{"auths": ...}' <12> -sshKey: 'ssh-ed25519 AAAA...' <13> + none: {} +fips: false +pullSecret: '{"auths": ...}' +sshKey: 'ssh-ed25519 AAAA...' ---- -<1> The base domain of the cluster. All DNS records must be sub-domains of this base and include the cluster name. -<2> The `controlPlane` section is a single mapping, but the `compute` section is a sequence of mappings. To meet the requirements of the different data structures, the first line of the `compute` section must begin with a hyphen, `-`, and the first line of the `controlPlane` section must not. Only one control plane pool is used. -<3> This parameter controls the number of compute machines that the Agent-based installation waits to discover before triggering the installation process. It is the number of compute machines that must be booted with the generated ISO. +where: +`baseDomain`:: Specifies the base domain of the cluster. All DNS records must be sub-domains of this base and include the cluster name. +`compute`:: Specifies a sequence of mappings. To meet the requirements of the different data structures, the first line of the `compute` section must begin with a hyphen, -. +`compute.replicas`:: Specifies the number of compute machines that the Agent-based Installer waits to discover before triggering the installation process. It is the number of compute machines that must be booted with the generated ISO. + [NOTE] ==== If you are installing a three-node cluster, do not deploy any compute machines when you install the {op-system-first} machines. ==== -+ -<4> The number of control plane machines that you add to the cluster. Because the cluster uses these values as the number of etcd endpoints in the cluster, the value must match the number of control plane machines that you deploy. -<5> The cluster name that you specified in your DNS records. -<6> A block of IP addresses from which pod IP addresses are allocated. This block must not overlap with existing physical networks. These IP addresses are used for the pod network. If you need to access the pods from an external network, you must configure load balancers and routers to manage the traffic. +`controlPlane`:: Specifies a single mapping. To meet the requirements of the different data structures, the first line of the `controlPlane` section must not begin with a hyphen, -. Only one control plane pool is used. +`controlPlane.replicas`:: Specifies the number of control plane machines that you add to the cluster. Because the cluster uses these values as the number of etcd endpoints in the cluster, the value must match the number of control plane machines that you deploy. +`metadata.name`:: Specifies the cluster name that you specified in your DNS records. +`networking.clusterNetwork.cidr`:: Specifies a block of IP addresses from which pod IP addresses are allocated. This block must not overlap with existing physical networks. These IP addresses are used for the pod network. If you need to access the pods from an external network, you must configure load balancers and routers to manage the traffic. + [NOTE] ==== Class E CIDR range is reserved for a future use. To use the Class E CIDR range, you must ensure your networking environment accepts the IP addresses within the Class E CIDR range. ==== -+ -<7> The subnet prefix length to assign to each individual node. For example, if `hostPrefix` is set to `23`, then each node is assigned a `/23` subnet out of the given `cidr`, which allows for 510 (2^(32 - 23) - 2) pod IP addresses. If you are required to provide access to nodes from an external network, configure load balancers and routers to manage the traffic. -<8> The cluster network plugin to install. The default value `OVNKubernetes` is the only supported value. -<9> The IP address pool to use for service IP addresses. You can enter only one IP address pool. This block must not overlap with existing physical networks. If you need to access the services from an external network, configure load balancers and routers to manage the traffic. -<10> You must set the platform to `none` for a single-node cluster. You can set the platform to `vsphere`, `baremetal`, or `none` for multi-node clusters. +`networking.clusterNetwork.hostPrefix`:: Specifies the subnet prefix length to assign to each individual node. For example, if `hostPrefix` is set to `23`, then each node is assigned a `/23` subnet out of the given `cidr`, which allows for 510 (2^(32 - 23) - 2) pod IP addresses. If you are required to provide access to nodes from an external network, configure load balancers and routers to manage the traffic. +`networking.networkType`:: Specifies the cluster network plugin to install. The default value `OVNKubernetes` is the only supported value. +`networking.serviceNetwork`:: Specifies the IP address pool to use for service IP addresses. You can enter only one IP address pool. This block must not overlap with existing physical networks. If you need to access the services from an external network, configure load balancers and routers to manage the traffic. +`platform.none`:: Specifies platform `none`. You must set the platform to `none` for a single-node cluster. You can set the platform to `vsphere`, `baremetal`, or `none` for multi-node clusters. + [NOTE] ==== @@ -96,15 +98,14 @@ platform: - 2001:DB8::5 ---- ==== -<11> Whether to enable or disable FIPS mode. By default, FIPS mode is not enabled. If FIPS mode is enabled, the {op-system-first} machines that {product-title} runs on bypass the default Kubernetes cryptography suite and use the cryptography modules that are provided with {op-system} instead. +`fips`:: Specifies whether to enable or disable FIPS mode. By default, FIPS mode is not enabled. If FIPS mode is enabled, the {op-system-first} machines that {product-title} runs on bypass the default Kubernetes cryptography suite and use the cryptography modules that are provided with {op-system} instead. + [IMPORTANT] ==== When running {op-system-base-full} or {op-system-first} booted in FIPS mode, {product-title} core components use the {op-system-base} cryptographic libraries that have been submitted to NIST for FIPS 140-2/140-3 Validation on only the x86_64, ppc64le, and s390x architectures. ==== - -<12> This pull secret allows you to authenticate with the services that are provided by the included authorities, including Quay.io, which serves the container images for {product-title} components. -<13> The SSH public key for the `core` user in {op-system-first}. +`pullSecret`:: Specifies a pull secret that allows you to authenticate with the services that are provided by the included authorities, including Quay.io, which serves the container images for {product-title} components. +`sshKey`:: Specifies the SSH public key for the `core` user in {op-system-first}. + [NOTE] ==== diff --git a/modules/understanding-agent-install.adoc b/modules/understanding-agent-install.adoc index 801ad5a8190b..ad89f3cb1b1b 100644 --- a/modules/understanding-agent-install.adoc +++ b/modules/understanding-agent-install.adoc @@ -6,9 +6,10 @@ [id="understanding-agent-install_{context}"] = Understanding Agent-based Installer +[role="_abstract"] As an {product-title} user, you can leverage the advantages of the Assisted Installer hosted service in disconnected environments. -The Agent-based installation comprises a bootable ISO that contains the Assisted discovery agent and the Assisted Service. Both are required to perform the cluster installation, but the latter runs on only one of the hosts. +The Agent-based Installer uses a bootable ISO that contains the Assisted discovery agent and the Assisted Service. Both are required to perform the cluster installation, but the Assisted Service runs on only one of the hosts. [NOTE] ==== @@ -17,12 +18,12 @@ Currently, ISO boot support on {ibm-z-name} (`s390x`) is available only for {op- The `openshift-install agent create image` subcommand generates an ephemeral ISO based on the inputs that you provide. You can choose to provide inputs through the following manifests: -Preferred: +Preferred manifests: * `install-config.yaml` * `agent-config.yaml` -Optional: ZTP manifests +Optional ZTP manifests: * `cluster-manifests/cluster-deployment.yaml` * `cluster-manifests/agent-cluster-install.yaml` @@ -35,23 +36,26 @@ Optional: ZTP manifests [id="agent-based-installer-workflow_{context}"] == Agent-based Installer workflow -One of the control plane hosts runs the Assisted Service at the start of the boot process and eventually becomes the bootstrap host. This node is called the *rendezvous host* (node 0). -The Assisted Service ensures that all the hosts meet the requirements and triggers an {product-title} cluster deployment. All the nodes have the Red Hat Enterprise Linux CoreOS (RHCOS) image written to the disk. The non-bootstrap nodes reboot and initiate a cluster deployment. -Once the nodes are rebooted, the rendezvous host reboots and joins the cluster. The bootstrapping is complete and the cluster is deployed. + +One of the control plane hosts runs the Assisted Service at the start of the boot process and eventually becomes the bootstrap host. This node is called the *rendezvous host* (or node 0). + +The Assisted Service ensures that all the hosts meet the requirements and triggers an {product-title} cluster deployment. All the nodes have the {op-system-base-full} image written to the disk. The non-bootstrap nodes reboot and initiate a cluster deployment. + +Once the nodes are rebooted, the rendezvous host reboots and joins the cluster. The bootstrapping is then complete and the cluster is deployed. .Node installation workflow image::agent-based-installer-workflow.png[Agent-based installer workflow] You can install a disconnected {product-title} cluster through the `openshift-install agent create image` subcommand for the following topologies: -* **A single-node {product-title} cluster (SNO)**: A node that is both a master and worker. -* **A three-node {product-title} cluster** : A compact cluster that has three master nodes that are also worker nodes. -* **Highly available {product-title} cluster (HA)**: Three master nodes with any number of worker nodes. +* **A single-node {product-title} cluster**: A node that is both a control plane and compute. +* **A three-node {product-title} cluster** : A compact cluster that has three control plane nodes that are also compute nodes. +* **Highly available {product-title} cluster (HA)**: Three control plane nodes with any number of compute nodes. [id="agent-based-installer-recommended-resources_{context}"] == Recommended resources for topologies -Recommended cluster resources for the following topologies: +The following cluster resources are recommended for each topology: .Recommended cluster resources [options="header"] @@ -81,7 +85,10 @@ Otherwise, it is recommended to provide more compute resources to the cluster. // These supported platforms are also documented in nodes/nodes/nodes-nodes-adding-node-iso.adoc and installation-configuration-parameters.adoc -In the `install-config.yaml`, specify the platform on which to perform the installation. The following platforms are supported: +[id="agent-based-installer-supported-platforms_{context}"] +== Supported platforms + +In the `install-config.yaml` file, specify the platform on which to perform the installation. The following platforms are supported: * `baremetal` * `vsphere` @@ -96,16 +103,16 @@ For a two-node {product-title} cluster with fencing (TNF), only the following pl * `none` + The `vsphere` and `nutanix` platforms are not supported for two-node clusters with fencing. -+ + [IMPORTANT] ==== For platform `none`: * The `none` option requires the provision of DNS name resolution and load balancing infrastructure in your cluster. See _Requirements for a cluster using the platform "none" option_ in the "Additional resources" section for more information. -* Review the information in the link:https://access.redhat.com/articles/4207611[guidelines for deploying {product-title} on non-tested platforms] before you attempt to install an {product-title} cluster in virtualized or cloud environments. +* See "Deploying OpenShift 4.x on non-tested platforms using the bare metal install method" before you attempt to install an {product-title} cluster in virtualized or cloud environments. ==== -+ + [NOTE] ==== For installations on {ibm-z-name} (`s390x`) architecture, the minimum memory requirement is 24 GB RAM per host instead of 16 GB. diff --git a/modules/validations-before-agent-iso-creation.adoc b/modules/validations-before-agent-iso-creation.adoc index 95d0774f59ce..680fa2acd18a 100644 --- a/modules/validations-before-agent-iso-creation.adoc +++ b/modules/validations-before-agent-iso-creation.adoc @@ -6,10 +6,10 @@ [id="validations-before-agent-iso-creation_{context}"] = Validation checks before agent ISO creation -The Agent-based Installer performs validation checks on user defined YAML files before the ISO is created. Once the validations are successful, the agent ISO -is created. +[role="_abstract"] +The Agent-based Installer performs validation checks on user defined YAML files before the ISO is created. Once the validations are successful, the agent ISO is created. -.`install-config.yaml` +`install-config.yaml`:: * `baremetal`, `vsphere` and `none` platforms are supported. * The `networkType` parameter must be `OVNKubernetes` in the case of `none` platform. @@ -17,14 +17,14 @@ is created. * Some host-specific fields in the bare metal platform configuration that have equivalents in `agent-config.yaml` file are ignored. A warning message is logged if these fields are set. -.`agent-config.yaml` +`agent-config.yaml`:: * Each interface must have a defined MAC address. Additionally, all interfaces must have a different MAC address. * At least one interface must be defined for each host. * World Wide Name (WWN) vendor extensions are not supported in root device hints. * The `role` parameter in the `host` object must have a value of either `master` or `worker`. -.Two-Node with Fencing (TNF) additional validation checks +Additional validation checks for Two-Node with Fencing (TNF):: * When the `controlPlane.replicas` parameter is set to `2`, you must provide exactly 2 fencing credentials. * Each fencing credential must include `hostName`, `address`, `username`, and `password`. @@ -34,13 +34,15 @@ is created. * Fencing credentials are valid only with `baremetal`, `external`, or `none` platforms. Other platforms result in a validation error. [id="agent-validations-ztp_{context}"] -== ZTP manifests +== Validation checks for ZTP manifests -.`agent-cluster-install.yaml` +The following validation checks are performed when using ZTP manifests: + +`agent-cluster-install.yaml`:: * For IPv6, the only supported value for the `networkType` parameter is `OVNKubernetes`. The `OpenshiftSDN` value can be used only for IPv4. -.`cluster-image-set.yaml` +`cluster-image-set.yaml`:: * The `ReleaseImage` parameter must match the release defined in the installer.