openshift · skopacz1 · Jun 18, 2026 · Jun 9, 2026
diff --git a/...with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc b/...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,22 +89,22 @@ 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]
 
 //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
@@ -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.
 ====
diff --git 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
@@ -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
@@ -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
@@ -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,43 +142,43 @@ 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
   server worker0 worker0.ocp4.example.com:80 check inter 1s
   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.