diff --git a/installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc b/installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc index f6059a194db..ed64db0c96d 100644 --- a/installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc +++ b/installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc @@ -5,6 +5,8 @@ include::_attributes/common-attributes.adoc[] :context: ipi-install-installation-workflow toc::[] +[role="_abstract"] +Before you can install an {product-title} cluster on bare metal, you must set up your environment for installation. // Installing {op-system-base} on the provisioner node include::modules/ipi-install-installing-rhel-on-the-provisioner-node.adoc[leveloffset=+1] @@ -18,9 +20,8 @@ include::modules/ipi-install-checking-ntp-sync.adoc[leveloffset=+1] [role="_additional-resources"] .Additional resources -* xref:../../../installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc#configuring-ntp-for-disconnected-clusters_ipi-install-installation-workflow[Optional: Configuring NTP for disconnected clusters] - * xref:../../../installing/installing_bare_metal/ipi/ipi-install-prerequisites.adoc#network-requirements-ntp_ipi-install-prerequisites[Network Time Protocol (NTP)] +* xref:../../../installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc#configuring-ntp-for-disconnected-clusters_ipi-install-installation-workflow[Optional: Configuring NTP for disconnected clusters] // Configuring networking include::modules/ipi-install-configuring-networking.adoc[leveloffset=+1] @@ -77,21 +78,14 @@ include::modules/local-arbiter-node-config-prerequisites.adoc[leveloffset=+1] // Configuring a local arbiter node include::modules/ipi-install-config-local-arbiter-node.adoc[leveloffset=+1] -.Next steps - -* xref:../../../installing/installing_bare_metal/ipi/ipi-install-installing-a-cluster.adoc#ipi-install-installing-a-cluster[Installing a cluster] - [role="_additional-resources"] .Additional resources +* xref:../../../installing/installing_bare_metal/ipi/ipi-install-installing-a-cluster.adoc#ipi-install-installing-a-cluster[Installing a cluster] * xref:../../../nodes/clusters/nodes-cluster-enabling-features.adoc#nodes-cluster-enabling-features-about_nodes-cluster-enabling-features[Understanding feature gates] -[id="ipi-install-configuration-files"] -[id="additional-resources_config"] -== Configuring the install-config.yaml file - // Configuring the install-config.yaml file -include::modules/ipi-install-configuring-the-install-config-file.adoc[leveloffset=+2] +include::modules/ipi-install-configuring-the-install-config-file.adoc[leveloffset=+1] // Additional `install-config` parameters include::modules/ipi-install-additional-install-config-parameters.adoc[leveloffset=+2] @@ -103,7 +97,6 @@ include::modules/ipi-install-bmc-addressing.adoc[leveloffset=+2] .Additional resources * xref:../../../vcp/vcp-overview.adoc#vcp-overview[Understanding virtualized control planes] - * xref:../../../installing/installing_bare_metal/bare-metal-postinstallation-configuration.adoc#bmo-editing-a-baremetalhost-resource_bare-metal-postinstallation-configuration[Editing a BareMetalHost resource] // Verifying support for the Redfish API @@ -156,11 +149,8 @@ include::modules/ipi-install-configure-multiple-cluster-nodes.adoc[leveloffset=+ // Optional: Configuring managed Secure Boot include::modules/ipi-install-configuring-managed-secure-boot-in-the-install-config-file.adoc[leveloffset=+2] -[id="ipi-install-manifest-configuration-files"] -== Manifest configuration files - // Creating the {product-title} manifests -include::modules/ipi-install-creating-the-openshift-manifests.adoc[leveloffset=+2] +include::modules/ipi-install-creating-the-openshift-manifests.adoc[leveloffset=+1] // Optional: Configuring NTP for disconnected clusters include::modules/ipi-install-configuring-ntp-for-disconnected-clusters.adoc[leveloffset=+2] @@ -197,11 +187,9 @@ include::modules/ipi-install-configuring-storage-on-nodes.adoc[leveloffset=+2] // Creating a disconnected registry include::modules/ipi-install-creating-a-disconnected-registry.adoc[leveloffset=+1] - -[id="prerequisites_ipi-disconnected-registry"] -=== Prerequisites - -* If you have already prepared a mirror registry for xref:../../../disconnected/installing-mirroring-installation-images.adoc#prerequisites_installing-mirroring-installation-images[Mirroring images for a disconnected installation], you can skip directly to xref:../../../installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc#ipi-modify-install-config-for-a-disconnected-registry_ipi-install-installation-workflow[Modify the install-config.yaml file to use the disconnected registry]. +[role="_additional-resources"] +.Additional resources +* xref:../../../disconnected/installing-mirroring-installation-images.adoc#prerequisites_installing-mirroring-installation-images[Mirroring images for a disconnected installation] // Preparing the registry node to host the mirrored registry include::modules/ipi-install-preparing-a-disconnected-registry.adoc[leveloffset=+2] diff --git a/modules/creating-manifest-file-customized-br-ex-bridge.adoc b/modules/creating-manifest-file-customized-br-ex-bridge.adoc index 1973c338c33..e0d09f96ae1 100644 --- a/modules/creating-manifest-file-customized-br-ex-bridge.adoc +++ b/modules/creating-manifest-file-customized-br-ex-bridge.adoc @@ -177,7 +177,7 @@ spec: ---- + where: -+ + `metadata.name`:: Specifies the name of the policy. `contents.source`:: Writes the encoded base64 information to the specified path. `path`:: For each node in your cluster, specify the hostname path to your node and the base-64 encoded Ignition configuration file data for the machine type. The `worker` role is the default role for nodes in your cluster. You must use the `.yml` extension for configuration files. For example, use `$(hostname -s).yml` when specifying the short hostname path for each node or all nodes in the `MachineConfig` manifest file. @@ -205,7 +205,7 @@ endif::agent[] ifndef::agent[] .Next steps -* Scaling compute nodes to apply the manifest object that includes a customized `br-ex` bridge to each compute node that exists in your cluster. For more information, see "Expanding the cluster" in the _Additional resources_ section. +* Scaling compute nodes to apply the manifest object that includes a customized `br-ex` bridge to each compute node that exists in your cluster. For more information, see "Expanding the cluster". endif::agent[] ifeval::["{context}" == "installing-with-agent-based-installer"] diff --git a/modules/creating-scaling-machine-sets-compute-nodes-networking.adoc b/modules/creating-scaling-machine-sets-compute-nodes-networking.adoc index 2937ca488ae..0dde6a3cf23 100644 --- a/modules/creating-scaling-machine-sets-compute-nodes-networking.adoc +++ b/modules/creating-scaling-machine-sets-compute-nodes-networking.adoc @@ -73,5 +73,7 @@ $ oc get machinesets ---- $ oc scale machineset --replicas= ---- -* : Where `` is the name of the machine set and `` is the number of compute nodes. +where: +``:: Specifies the name of the machine set. +``:: Specifies the number of compute nodes. diff --git a/modules/ipi-install-checking-ntp-sync.adoc b/modules/ipi-install-checking-ntp-sync.adoc index 1038846c79e..a1fa1e1902d 100644 --- a/modules/ipi-install-checking-ntp-sync.adoc +++ b/modules/ipi-install-checking-ntp-sync.adoc @@ -7,9 +7,10 @@ [id="checking-ntp-sync_{context}"] = Checking NTP server synchronization +[role="_abstract"] The {product-title} installation program installs the `chrony` Network Time Protocol (NTP) service on the cluster nodes. To complete installation, each node must have access to an NTP time server. You can verify NTP server synchronization by using the `chrony` service. -For disconnected clusters, you must configure the NTP servers on the control plane nodes. For more information see the _Additional resources_ section. +For disconnected clusters, you must configure the NTP servers on the control plane nodes. For more information see "Configuring NTP for disconnected clusters". .Prerequisites diff --git a/modules/ipi-install-config-local-arbiter-node.adoc b/modules/ipi-install-config-local-arbiter-node.adoc index 8cbd3d95bc7..29cdb742dc4 100644 --- a/modules/ipi-install-config-local-arbiter-node.adoc +++ b/modules/ipi-install-config-local-arbiter-node.adoc @@ -29,20 +29,20 @@ compute: name: worker platform: {} replicas: 0 -arbiter: <1> +arbiter: architecture: amd64 hyperthreading: Enabled - replicas: 1 <2> - name: arbiter <3> + replicas: 1 + name: arbiter platform: baremetal: {} -controlPlane: <4> +controlPlane: architecture: amd64 hyperthreading: Enabled name: master platform: baremetal: {} - replicas: 2 <5> + replicas: 2 platform: baremetal: # ... @@ -57,10 +57,12 @@ platform: role: arbiter # ... ---- -<1> Defines the arbiter machine pool. You must configure this field to deploy a cluster with an arbiter node. -<2> Set the `replicas` field to `1` for the arbiter pool. You cannot set this field to a value that is greater than 1. -<3> Specifies a name for the arbiter machine pool. -<4> Defines the control plane machine pool. -<5> When an arbiter pool is defined, two control plane replicas are valid. +where: + +`arbiter`:: Specifies the arbiter machine pool. You must configure this field to deploy a cluster with an arbiter node. +`arbiter.replicas`:: Specifies the value for the `arbiter.replicas` parameter. Set the `replicas` field to `1` for the arbiter pool. You cannot set this field to a value that is greater than 1. +`arbiter.name`:: Specifies a name for the arbiter machine pool. +`controlPlane`:: Specifies the control plane machine pool. +`controlPlane.replicas`:: Specifies the value for the `controlPlane.replicas` parameter. When an arbiter pool is defined, two control plane replicas are valid. . Save the modified `install-config.yaml` file. \ No newline at end of file diff --git a/modules/ipi-install-configuring-networking.adoc b/modules/ipi-install-configuring-networking.adoc index 1856edbc508..b55261dc8e3 100644 --- a/modules/ipi-install-configuring-networking.adoc +++ b/modules/ipi-install-configuring-networking.adoc @@ -6,6 +6,7 @@ [id="configuring-networking_{context}"] = Configuring networking +[role="_abstract"] Before installation, you must configure networking settings for the provisioner node. Installer-provisioned clusters deploy with a bare-metal bridge and network resources, and an optional provisioning bridge and network resources. image::210_OpenShift_Baremetal_IPI_Deployment_updates_0122_1.png[Configure networking] @@ -36,7 +37,7 @@ $ nmcli con delete "System " ---- + where: -+ + ``:: Replace `` with the name of your network interface controller (NIC). + .. For a network that uses Dynamic Host Configuration Protocol (DHCP), create an NMState YAML file and specify the bare-metal bridge interface and any physical interfaces in the file: @@ -110,7 +111,7 @@ interfaces: ---- + where: -+ + ``:: Defines the DNS server for your bare-metal system. ``:: Replace `` with the IP address for the DNS server. ``:: Defines the bridge interface and its static IP configuration. diff --git a/modules/ipi-install-configuring-ntp-for-disconnected-clusters.adoc b/modules/ipi-install-configuring-ntp-for-disconnected-clusters.adoc index ffbf8223acf..b3a75cf025f 100644 --- a/modules/ipi-install-configuring-ntp-for-disconnected-clusters.adoc +++ b/modules/ipi-install-configuring-ntp-for-disconnected-clusters.adoc @@ -85,13 +85,10 @@ storage: # Serve time even if not synchronized to a time source. local stratum 3 orphan ---- -+ where: -+ --- + ``:: Specifies the name of the cluster. ``:: Specifies the fully qualified domain name. --- . Use Butane to generate a `MachineConfig` object file, `99-master-chrony-conf-override.yaml`, containing the configuration to be delivered to the control plane nodes: + @@ -135,13 +132,10 @@ storage: logchange 0.5 logdir /var/log/chrony ---- -+ where: -+ --- + ``:: Specifies the name of the cluster. ``:: Specifies the fully qualified domain name. --- . Use Butane to generate a `MachineConfig` object file, `99-worker-chrony-conf-override.yaml`, containing the configuration to be delivered to the worker nodes: + diff --git a/modules/ipi-install-configuring-the-install-config-file.adoc b/modules/ipi-install-configuring-the-install-config-file.adoc index c6a84c2a3f5..24f1dc7fa6c 100644 --- a/modules/ipi-install-configuring-the-install-config-file.adoc +++ b/modules/ipi-install-configuring-the-install-config-file.adoc @@ -6,6 +6,7 @@ [id="configuring-the-install-config-file_{context}"] = Configuring the install-config.yaml file +[role="_abstract"] The `install-config.yaml` file requires some additional details. Most of the information teaches the installation program and the resulting cluster enough about the available hardware that it is able to fully manage it. @@ -14,6 +15,8 @@ Most of the information teaches the installation program and the resulting clust The installation program no longer needs the `clusterOSImage` {op-system} image because the correct image is in the release payload. ==== +.Procedure + . Configure `install-config.yaml`. Change the appropriate variables to match the environment, including `pullSecret` and `sshKey`: + [source,yaml] @@ -28,7 +31,7 @@ networking: networkType: OVNKubernetes compute: - name: worker - replicas: 2 <1> + replicas: 2 controlPlane: name: master replicas: 3 @@ -36,26 +39,26 @@ controlPlane: baremetal: {} platform: baremetal: - additionalNTPServers: <2> + additionalNTPServers: - apiVIPs: - ingressVIPs: - provisioningNetworkCIDR: - bootstrapExternalStaticIP: <3> - bootstrapExternalStaticGateway: <4> - bootstrapExternalStaticDNS: <5> + bootstrapExternalStaticIP: + bootstrapExternalStaticGateway: + bootstrapExternalStaticDNS: hosts: - name: openshift-master-0 role: master bmc: - address: ipmi:// <6> + address: ipmi:// username: password: bootMACAddress: rootDeviceHints: - deviceName: "" <7> + deviceName: "" - name: role: master bmc: @@ -94,14 +97,15 @@ pullSecret: '' sshKey: '' ---- + --- -<1> Scale the compute machines based on the number of compute nodes that are part of the {product-title} cluster. Valid options for the `replicas` value are `0` and integers greater than or equal to `2`. Set the number of replicas to `0` to deploy a three-node cluster, which contains only three control plane machines. A three-node cluster is a smaller, more resource-efficient cluster that can be used for testing, development, and production. You cannot install the cluster with only one compute node. -<2> An optional list of additional NTP server domain names or IP addresses to add to each host configuration when the cluster host clocks are out of synchronization. -<3> When deploying a cluster with static IP addresses, you must set the `bootstrapExternalStaticIP` configuration setting to specify the static IP address of the bootstrap VM when there is no DHCP server on the bare metal network. -<4> When deploying a cluster with static IP addresses, you must set the `bootstrapExternalStaticGateway` configuration setting to specify the gateway IP address for the bootstrap VM when there is no DHCP server on the bare metal network. -<5> When deploying a cluster with static IP addresses, you must set the `bootstrapExternalStaticDNS` configuration setting to specify the DNS address for the bootstrap VM when there is no DHCP server on the bare metal network. -<6> See the BMC addressing sections for more options. -<7> To set the path to the installation disk drive, enter the kernel name of the disk. For example, `/dev/sda`. +where: + +`compute.replicas`:: Specifies the value for the `compute.replicas` parameter. Scale the compute machines based on the number of compute nodes that are part of the {product-title} cluster. Valid options for the `replicas` value are `0` and integers greater than or equal to `2`. Set the number of replicas to `0` to deploy a three-node cluster, which contains only three control plane machines. A three-node cluster is a smaller, more resource-efficient cluster that can be used for testing, development, and production. You cannot install the cluster with only one compute node. +`platform.baremetal.additionalNTPServers`:: Specifies the optional list of additional NTP server domain names or IP addresses to add to each host configuration when the cluster host clocks are out of synchronization. +`platform.baremetal.bootstrapExternalStaticIP`:: Specifies the value for the `bootstrapExternalStaticIP` parameter. When deploying a cluster with static IP addresses, you must set the `bootstrapExternalStaticIP` configuration setting to specify the static IP address of the bootstrap VM when there is no DHCP server on the bare metal network. +`platform.baremetal.bootstrapExternalStaticGateway`:: Specifies the value for the `bootstrapExternalStaticGateway` parameter. When deploying a cluster with static IP addresses, you must set the `bootstrapExternalStaticGateway` configuration setting to specify the gateway IP address for the bootstrap VM when there is no DHCP server on the bare metal network. +`platform.baremetal.bootstrapExternalStaticDNS`:: Specifies the value for the `bootstrapExternalStaticDNS` parameter. When deploying a cluster with static IP addresses, you must set the `bootstrapExternalStaticDNS` configuration setting to specify the DNS address for the bootstrap VM when there is no DHCP server on the bare metal network. +`platform.baremetal.hosts.bmc.address`:: Specifies the value for the `platform.baremetal.hosts.bmc.address` parameter. See the BMC addressing sections for more options. +`platform.baremetal.hosts.rootDeviceHints.deviceName`:: Specifies the value for the `platform.baremetal.hosts.rootDeviceHints.deviceName` parameter. To set the path to the installation disk drive, enter the kernel name of the disk. For example, `/dev/sda`. + [IMPORTANT] ==== @@ -117,12 +121,12 @@ Failure to meet these requirements for the `rootDeviceHints` parameter might res ironic-inspector inspection failed: No disks satisfied root device hints ---- ==== - ++ [NOTE] ==== Before {product-title} 4.12, the cluster installation program only accepted an IPv4 address or an IPv6 address for the `apiVIP` and `ingressVIP` configuration settings. In {product-title} 4.12 and later, these configuration settings are deprecated. Instead, use a list format in the `apiVIPs` and `ingressVIPs` configuration settings to specify IPv4 addresses, IPv6 addresses, or both IP address formats. ==== --- + . Create a directory to store the cluster configuration: + [source,terminal] diff --git a/modules/ipi-install-creating-a-disconnected-registry.adoc b/modules/ipi-install-creating-a-disconnected-registry.adoc index fc659a5a896..2402f7f4299 100644 --- a/modules/ipi-install-creating-a-disconnected-registry.adoc +++ b/modules/ipi-install-creating-a-disconnected-registry.adoc @@ -7,6 +7,7 @@ [id="ipi-install-creating-a-disconnected-registry_{context}"] = Creating a disconnected registry +[role="_abstract"] In some cases, you might want to install an {product-title} cluster using a local copy of the installation registry. This could be for enhancing network efficiency because the cluster nodes are on a network that does not have access to the internet. A local, or mirrored, copy of the registry requires the following: @@ -17,5 +18,6 @@ A local, or mirrored, copy of the registry requires the following: [NOTE] ==== -Creating a disconnected registry on a registry node is optional. If you need to create a disconnected registry on a registry node, you must complete all of the following sub-sections. +* Creating a disconnected registry on a registry node is optional. If you need to create a disconnected registry on a registry node, you must complete all of the following sub-sections. +* If you have already prepared a mirror registry for a disconnected installation by mirroring images, you can skip directly to "Modify the install-config.yaml file to use the disconnected registry" section. For more information about preparing a mirror registry for a disconnected installation by mirroring images see, "Mirroring images for a disconnected installation". ==== diff --git a/modules/ipi-install-creating-an-rhcos-images-cache.adoc b/modules/ipi-install-creating-an-rhcos-images-cache.adoc index ea3c43f3268..c11128f461e 100644 --- a/modules/ipi-install-creating-an-rhcos-images-cache.adoc +++ b/modules/ipi-install-creating-an-rhcos-images-cache.adoc @@ -6,6 +6,7 @@ [id="ipi-install-creating-an-rhcos-images-cache_{context}"] = Creating an {op-system} images cache +[role="_abstract"] To employ image caching, you must download the {op-system-first} image used by the bootstrap VM to provision the cluster nodes. Image caching is optional, but it is especially useful when running the installation program on a network with limited bandwidth. [NOTE] @@ -101,13 +102,12 @@ $ ls -Z /home/kni/rhcos_image_cache + [source,terminal] ---- -$ podman run -d --name rhcos_image_cache \// <1> +$ podman run -d --name rhcos_image_cache \ -v /home/kni/rhcos_image_cache:/var/www/html \ -p 8080:8080/tcp \ registry.access.redhat.com/ubi9/httpd-24 ---- -+ -<1> Creates a caching webserver with the name `rhcos_image_cache`. This pod serves the `bootstrapOSImage` image in the `install-config.yaml` file for deployment. +This command creates a caching webserver with the name `rhcos_image_cache`. This pod serves the `bootstrapOSImage` image in the `install-config.yaml` file for deployment. . Generate the `bootstrapOSImage` configuration: + @@ -132,8 +132,9 @@ $ echo " bootstrapOSImage=${BOOTSTRAP_OS_IMAGE}" ---- platform: baremetal: - bootstrapOSImage: <1> + bootstrapOSImage: ---- -<1> Replace `` with the value of `$BOOTSTRAP_OS_IMAGE`. ++ +Replace `` with the value of `$BOOTSTRAP_OS_IMAGE`. + See the "Configuring the install-config.yaml file" section for additional details. diff --git a/modules/ipi-install-establishing-communication-between-subnets.adoc b/modules/ipi-install-establishing-communication-between-subnets.adoc index e3f5afc7e70..5221e78d50a 100644 --- a/modules/ipi-install-establishing-communication-between-subnets.adoc +++ b/modules/ipi-install-establishing-communication-between-subnets.adoc @@ -6,7 +6,10 @@ [id="ipi-install-establishing-communication-between-subnets_{context}"] = Establishing communication between subnets -In a typical {product-title} cluster setup, all nodes, including the control plane and compute nodes, reside in the same network. However, for edge computing scenarios, it can be beneficial to locate compute nodes closer to the edge. This often involves using different network segments or subnets for the remote nodes than the subnet used by the control plane and local compute nodes. Such a setup can reduce latency for the edge and allow for enhanced scalability. +[role="_abstract"] +In a typical {product-title} cluster setup, all nodes, including the control plane and compute nodes, reside in the same network. However, for edge computing scenarios, it can be beneficial to locate compute nodes closer to the edge. + +This often involves using different network segments or subnets for the remote nodes than the subnet used by the control plane and local compute nodes. Such a setup can reduce latency for the edge and allow for enhanced scalability. Before installing {product-title}, you must configure the network properly to ensure that the edge subnets containing the remote nodes can reach the subnet containing the control plane nodes and receive traffic from the control plane too. @@ -63,7 +66,6 @@ $ sudo su - Replace `` with the interface name. Replace `` with the IP address of the actual gateway. + .Example -+ [source,terminal] ---- # nmcli connection modify eth0 +ipv4.routes "192.168.0.0/24 via 192.168.0.1" @@ -118,7 +120,6 @@ $ sudo su - Replace `` with the interface name. Replace `` with the IP address of the actual gateway. + .Example -+ [source,terminal] ---- # nmcli connection modify eth0 +ipv4.routes "10.0.0.0/24 via 10.0.0.1" diff --git a/modules/ipi-install-extracting-the-openshift-installer.adoc b/modules/ipi-install-extracting-the-openshift-installer.adoc index 402a19e8d8a..8fce4deca6b 100644 --- a/modules/ipi-install-extracting-the-openshift-installer.adoc +++ b/modules/ipi-install-extracting-the-openshift-installer.adoc @@ -6,7 +6,8 @@ [id="extracting-the-openshift-installer_{context}"] = Extracting the {product-title} installer -After retrieving the installer, the next step is to extract it. +[role="_abstract"] +Extract the {product-title} installer after retrieving it to prepare for the installation of the cluster. .Procedure diff --git a/modules/ipi-install-installing-rhel-on-the-provisioner-node.adoc b/modules/ipi-install-installing-rhel-on-the-provisioner-node.adoc index b2c81008346..9a34923d264 100644 --- a/modules/ipi-install-installing-rhel-on-the-provisioner-node.adoc +++ b/modules/ipi-install-installing-rhel-on-the-provisioner-node.adoc @@ -3,8 +3,11 @@ // * list of assemblies where this module is included // ipi-install-installation-workflow.adoc -:_mod-docs-content-type: PROCEDURE +:_mod-docs-content-type: CONCEPT [id="installing-rhel-on-the-provisioner-node_{context}"] -= Installing {op-system-base} on the provisioner node += Installations {op-system-base} on the provisioner node -With the configuration of the prerequisites complete, the next step is to install {op-system-base} {op-system-version} on the provisioner node. The installer uses the provisioner node as the orchestrator while installing the {product-title} cluster. For the purposes of this document, installing {op-system-base} on the provisioner node is out of scope. However, options include but are not limited to using a RHEL Satellite server, PXE, or installation media. +[role="_abstract"] +With the configuration of the prerequisites complete, the next step is to install {op-system-base} {op-system-version} on the provisioner node. The installer uses the provisioner node as the orchestrator while installing the {product-title} cluster. + +For the purposes of this document, installing {op-system-base} on the provisioner node is out of scope. However, options include but are not limited to using a RHEL Satellite server, PXE, or installation media. diff --git a/modules/ipi-install-preparing-the-provisioner-node-for-openshift-install.adoc b/modules/ipi-install-preparing-the-provisioner-node-for-openshift-install.adoc index b984677f7d4..a28fd950b1f 100644 --- a/modules/ipi-install-preparing-the-provisioner-node-for-openshift-install.adoc +++ b/modules/ipi-install-preparing-the-provisioner-node-for-openshift-install.adoc @@ -9,7 +9,8 @@ [id="preparing-the-provisioner-node-for-openshift-install_{context}"] = Preparing the provisioner node for {product-title} installation -Perform the following steps to prepare the environment. +[role="_abstract"] +Begin to set up your environment for cluster installation by preparing the provisioner node. .Procedure diff --git a/modules/ipi-install-retrieving-the-openshift-installer.adoc b/modules/ipi-install-retrieving-the-openshift-installer.adoc index 1b06df720bb..ba0f48964b6 100644 --- a/modules/ipi-install-retrieving-the-openshift-installer.adoc +++ b/modules/ipi-install-retrieving-the-openshift-installer.adoc @@ -6,16 +6,23 @@ [id="retrieving-the-openshift-installer_{context}"] = Retrieving the {product-title} installer -Use the `stable-4.x` version of the installation program and your selected architecture to deploy the generally available stable version of {product-title}: +[role="_abstract"] +Use the `stable-4.x` version of the installation program and your selected architecture to deploy the generally available stable version of {product-title}. +.Procedure + +* Retrieve the installation program by running one of the following commands: ++ [source,terminal,subs="attributes+"] ---- $ export VERSION=stable-{product-version} ---- ++ [source,terminal,subs="attributes+"] ---- $ export RELEASE_ARCH= ---- ++ [source,terminal,subs="attributes+"] ---- $ export RELEASE_IMAGE=$(curl -s https://mirror.openshift.com/pub/openshift-v4/$RELEASE_ARCH/clients/ocp/$VERSION/release.txt | grep 'Pull From: quay.io' | awk -F ' ' '{print $3}') diff --git a/modules/ipi-install-setting-cluster-node-hostnames-dhcp.adoc b/modules/ipi-install-setting-cluster-node-hostnames-dhcp.adoc index 6d1ed264290..f8a2d910f77 100644 --- a/modules/ipi-install-setting-cluster-node-hostnames-dhcp.adoc +++ b/modules/ipi-install-setting-cluster-node-hostnames-dhcp.adoc @@ -6,13 +6,16 @@ [id="ipi-install-setting-cluster-node-hostnames-dhcp_{context}"] = Setting the cluster node hostnames through DHCP -On {op-system-first} machines, `NetworkManager` sets the hostnames. By default, DHCP provides the hostnames to `NetworkManager`, which is the recommended method. `NetworkManager` gets the hostnames through a reverse DNS lookup in the following cases: +[role="_abstract"] +On {op-system-first} machines, `NetworkManager` sets the hostnames. By default, DHCP provides the hostnames to `NetworkManager`, which is the recommended method. + +The `NetworkManager` gets the hostnames through a reverse DNS lookup in the following cases: * If DHCP does not provide the hostnames * If you use kernel arguments to set the hostnames * If you use another method to set the hostnames -Reverse DNS lookup occurs after the network has been initialized on a node, and can increase the time it takes `NetworkManager` to set the hostname. Other system services can start prior to `NetworkManager` setting the hostname, which can cause those services to use a default hostname such as `localhost`. +Reverse DNS lookup occurs after the network has been initialized on a node, and can increase the time it takes `NetworkManager` to set the hostname. Other system services can start before `NetworkManager` setting the hostname, which can cause those services to use a default hostname such as `localhost`. [TIP] ==== diff --git a/modules/nw-osp-configuring-external-load-balancer.adoc b/modules/nw-osp-configuring-external-load-balancer.adoc index 19a229b9ffc..52ef34f1948 100644 --- a/modules/nw-osp-configuring-external-load-balancer.adoc +++ b/modules/nw-osp-configuring-external-load-balancer.adoc @@ -247,7 +247,7 @@ If the configuration is correct, you receive a JSON object in response: "platform": "linux/amd64" } ---- -+ + .. Verify that the cluster machine configuration API is accessible to the Machine config server resource, by running the following command and observing the output: + [source,terminal] @@ -351,7 +351,7 @@ endif::vsphere[] ---- + where: -+ + ``:: Specifies the load balancer type. Set to `UserManaged` to specify a user-managed load balancer for your cluster. The parameter defaults to `OpenShiftManagedDefault`, which denotes the default internal load balancer. For services defined in an `openshift-kni-infra` namespace, a user-managed load balancer can deploy the `coredns` service to pods in your cluster but ignores `keepalived` and `haproxy` services. ``:: Specifies the user-managed load balancer's public IP address for the Kubernetes API. Mandatory parameter. ``:: Specifies the user-managed load balancer's public IP address for ingress traffic. Mandatory parameter. @@ -383,7 +383,7 @@ If the configuration is correct, you receive a JSON object in response: "platform": "linux/amd64" } ---- -+ + .. Verify that you can access the cluster machine configuration, by running the following command and observing the output: + [source,terminal]