Merge pull request #44951 from johnwilkins/add-content-type-tags

skrthomas · web-flow · commit 257fd78b3329 · 2022-04-26T09:49:52.000-04:00
BZ 2004210: Add :_content-type: tags to IPI modules that do not have them.
diff --git a/modules/ipi-install-additional-install-config-parameters.adoc b/modules/ipi-install-additional-install-config-parameters.adoc
@@ -2,6 +2,7 @@
 //
 // * installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc
 
+:_content-type: REFERENCE
 [id="additional-install-config-parameters_{context}"]
 = Additional `install-config` parameters
 
diff --git a/modules/ipi-install-bmc-addressing-for-dell-idrac.adoc b/modules/ipi-install-bmc-addressing-for-dell-idrac.adoc
@@ -2,6 +2,7 @@
 //
 // installing/installing_bare_metal_ipi/ipi-install-configuration-files.adoc
 
+:_content-type: REFERENCE
 [id='bmc-addressing-for-dell-idrac_{context}']
 = BMC addressing for Dell iDRAC
 
diff --git a/modules/ipi-install-bmc-addressing-for-fujitsu-irmc.adoc b/modules/ipi-install-bmc-addressing-for-fujitsu-irmc.adoc
@@ -2,6 +2,7 @@
 //
 // installing/installing_bare_metal_ipi/ipi-install-configuration-files.adoc
 
+:_content-type: REFERENCE
 [id='bmc-addressing-for-fujitsu-irmc_{context}']
 = BMC addressing for Fujitsu iRMC
 
diff --git a/modules/ipi-install-bmc-addressing-for-hpe-ilo.adoc b/modules/ipi-install-bmc-addressing-for-hpe-ilo.adoc
@@ -2,6 +2,7 @@
 //
 // installing/installing_bare_metal_ipi/ipi-install-configuration-files.adoc
 
+:_content-type: REFERENCE
 [id='bmc-addressing-for-hpe-ilo_{context}']
 = BMC addressing for HPE iLO
 
diff --git a/modules/ipi-install-bmc-addressing.adoc b/modules/ipi-install-bmc-addressing.adoc
@@ -1,8 +1,9 @@
 // This is included in the following assemblies:
 //
 // installing/installing_bare_metal_ipi/ipi-install-configuration-files.adoc
-[id='bmc-addressing_{context}']
 
+:_content-type: REFERENCE
+[id='bmc-addressing_{context}']
 = BMC addressing
 
 Most vendors support Baseboard Management Controller (BMC) addressing with the Intelligent Platform Management Interface (IPMI). IPMI does not encrypt communications. It is suitable for use within a data center over a secured or dedicated management network. Check with your vendor to see if they support Redfish network boot. Redfish delivers simple and secure management for converged, hybrid IT and the Software Defined Data Center (SDDC). Redfish is human readable and machine capable, and leverages common internet and web services standards to expose information directly to the modern tool chain. If your hardware does not support Redfish network boot, use IPMI.
diff --git a/modules/ipi-install-configuring-bios-for-worker-node.adoc b/modules/ipi-install-configuring-bios-for-worker-node.adoc
@@ -1,21 +1,26 @@
 // Module included in the following assemblies:
 //
 // * installing/installing_bare_metal_ipi/ipi-install-configuration-files.adoc
+
 :_content-type: PROCEDURE
 [id="configuring-bios-for-worker-node_{context}"]
-= Configuring BIOS for worker node
+= Configuring the BIOS for worker nodes
 
-The following procedure configures BIOS for the worker node during the installation process.
+The following procedure configures the BIOS for a worker node during the installation process.
 
 .Procedure
-. Create manifests.
+. Create the manifests.
+
 . Modify the BMH file corresponding to the worker:
 +
+[source,terminal]
 ----
 $ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-3.yaml
 ----
+
 . Add the BIOS configuration to the `spec` section of the BMH file:
 +
+[source,terminal]
 ----
 spec:
   firmware:
@@ -26,6 +31,7 @@ spec:
 +
 [NOTE]
 ====
-. Red Hat supports three BIOS configurations. See the link:https://github.com/openshift/baremetal-operator/blob/master/docs/api.md#firmware[BMH documentation] for details. Only servers with bmc type `irmc` are supported. Other types of servers are currently not supported.
+. Red Hat supports three BIOS configurations. See the link:https://github.com/openshift/baremetal-operator/blob/master/docs/api.md#firmware[BMH documentation] for details. Only servers with BMC type `irmc` are supported. Other types of servers are currently not supported.
 ====
-. Create cluster.
+
+. Create the cluster.
diff --git a/modules/ipi-install-configuring-host-network-interfaces-in-the-install-config.yaml-file.adoc b/modules/ipi-install-configuring-host-network-interfaces-in-the-install-config.yaml-file.adoc
@@ -2,6 +2,7 @@
 //
 // installing_bare_metal_ipi/ipi-install-installation-workflow.adoc
 
+:_content-type: PROCEDURE
 [id="configuring-host-network-interfaces-in-the-install-config-yaml-file_{context}"]
 = (Optional) Configuring host network interfaces in the `install-config.yaml` file
 
diff --git a/modules/ipi-install-configuring-managed-secure-boot-in-the-install-config-file.adoc b/modules/ipi-install-configuring-managed-secure-boot-in-the-install-config-file.adoc
@@ -2,6 +2,7 @@
 //
 // installing/installing_bare_metal_ipi/ipi-install-configuration-files.adoc
 
+:_content-type: PROCEDURE
 [id="configuring-managed-secure-boot-in-the-install-config-file_{context}"]
 = (Optional) Configuring managed Secure Boot in the `install-config.yaml` file
 
diff --git a/modules/ipi-install-configuring-nodes.adoc b/modules/ipi-install-configuring-nodes.adoc
@@ -2,6 +2,7 @@
 //
 // * installing/installing_bare_metal_ipi/ipi-install-prerequisites.adoc
 
+:_content-type: PROCEDURE
 [id="configuring-nodes_{context}"]
 = Configuring nodes
 
@@ -15,7 +16,7 @@ Each node in the cluster requires the following configuration for proper install
 A mismatch between nodes will cause an installation failure.
 ====
 
-While the cluster nodes can contain more than two NICs, the installation process only focuses on the first two NICs. In the following table, NIC1 is a non-routable network (`provisioning`) that is only used for the installation of the {product-title} cluster. 
+While the cluster nodes can contain more than two NICs, the installation process only focuses on the first two NICs. In the following table, NIC1 is a non-routable network (`provisioning`) that is only used for the installation of the {product-title} cluster.
 
 [options="header"]
 |===
diff --git a/modules/ipi-install-configuring-raid-for-worker-node.adoc b/modules/ipi-install-configuring-raid-for-worker-node.adoc
@@ -1,19 +1,22 @@
 // Module included in the following assemblies:
 //
 // * installing/installing_bare_metal_ipi/ipi-install-configuration-files.adoc
+
+:_content-type: PROCEDURE
 [id="configuring-raid-for-worker-node_{context}"]
-= Configuring RAID for worker node
+= Configuring RAID for worker nodes
 
 The following procedure configures RAID (Redundant Array of Independent Disks) for the worker node during the installation process.
 
 [NOTE]
 ====
-. Only servers with BMC (Baseboard Management Controller) type `irmc` are supported. Other types of servers are currently not supported.
-. If you want to configure hardware RAID for the server, make sure the server has a RAID controller.
+. Only nodes with BMC (Baseboard Management Controller) type `irmc` are supported. Other types of nodes are currently not supported.
+. If you want to configure hardware RAID for the node, make sure the node has a RAID controller.
 ====
 
 .Procedure
 . Create manifests.
+
 . Modify the BMH (Bare Metal Host) file corresponding to the worker:
 +
 [source,terminal]
@@ -23,10 +26,10 @@ $ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-3.yaml
 +
 [NOTE]
 ====
-Because servers with BMC type `irmc` do not support software RAID, the following RAID configuration uses hardware RAID as an example.
+Because nodes with BMC type `irmc` do not support software RAID, the following RAID configuration uses hardware RAID as an example.
 ====
 +
-.. If you added specific RAID configuration to the spec, this causes the worker node to delete the original RAID configuration in the `preparing` phase and perform a specified configuration on the RAID. For example:
+.. If you added a specific RAID configuration to the `spec` section, this causes the worker node to delete the original RAID configuration in the `preparing` phase and perform a specified configuration on the RAID. For example:
 +
 [source,yaml]
 ----
@@ -41,7 +44,7 @@ spec:
 ----
 <1> `level` is a required field, and the others are optional fields.
 +
-.. If you added an empty RAID configuration to the spec, this empty configuration causes the worker node to delete the original RAID configuration during the `preparing` phase, but does not perform a new configuration. For example:
+.. If you added an empty RAID configuration to the `spec` section, this empty configuration causes the worker node to delete the original RAID configuration during the `preparing` phase, but does not perform a new configuration. For example:
 +
 [source,yaml]
 ----
@@ -50,5 +53,6 @@ spec:
     hardwareRAIDVolumes: []
 ----
 +
-.. If you do not add a `raid` field in the spec, the original RAID configuration is not deleted, and no new configuration will be performed.
+.. If you do not add a `raid` field in the `spec` section, the original RAID configuration is not deleted, and no new configuration will be performed.
+
 . Create cluster.
diff --git a/modules/ipi-install-configuring-the-install-config-file.adoc b/modules/ipi-install-configuring-the-install-config-file.adoc
@@ -2,6 +2,7 @@
 //
 // * installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc
 
+:_content-type: PROCEDURE
 [id="configuring-the-install-config-file_{context}"]
 = Configuring the `install-config.yaml` file
 
diff --git a/modules/ipi-install-configuring-the-metal3-config-file.adoc b/modules/ipi-install-configuring-the-metal3-config-file.adoc
@@ -2,8 +2,8 @@
 //
 // * installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc
 
+:_content-type: PROCEDURE
 [id="configuring-the-metal3-config-file_{context}"]
-
 = Configuring the `metal3-config.yaml` file
 
 You must create and configure a ConfigMap `metal3-config.yaml` file.
diff --git a/modules/ipi-install-creating-the-openshift-manifests.adoc b/modules/ipi-install-creating-the-openshift-manifests.adoc
@@ -2,6 +2,7 @@
 //
 // * installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc
 
+:_content-type: PROCEDURE
 [id="creating-the-openshift-manifests_{context}"]
 = Creating the {product-title} manifests
 
diff --git a/modules/ipi-install-deploying-routers-on-worker-nodes.adoc b/modules/ipi-install-deploying-routers-on-worker-nodes.adoc
@@ -5,7 +5,6 @@
 
 :_content-type: PROCEDURE
 [id="deploying-routers-on-worker-nodes_{context}"]
-
 = Deploying routers on worker nodes
 
 During installation, the installer deploys router pods on worker nodes. By default, the installer installs two router pods. If the initial cluster has only one worker node, or if a deployed cluster requires additional routers to handle external traffic loads destined for services within the {product-title} cluster, you can create a `yaml` file to set an appropriate number of router replicas.
diff --git a/modules/ipi-install-deploying-the-cluster-via-the-openshift-installer.adoc b/modules/ipi-install-deploying-the-cluster-via-the-openshift-installer.adoc
@@ -2,6 +2,7 @@
 //
 // * installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc
 
+:_content-type: PROCEDURE
 [id='deploying-the-cluster-via-the-openshift-installer_{context}']
 = Deploying the cluster via the {product-title} installer
 
diff --git a/modules/ipi-install-firmware-requirements-for-installing-with-virtual-media.adoc b/modules/ipi-install-firmware-requirements-for-installing-with-virtual-media.adoc
@@ -2,6 +2,7 @@
 //
 // * installing/installing_bare_metal_ipi/ipi-install-prerequisites.adoc
 
+:_content-type: CONCEPT
 [id='ipi-install-firmware-requirements-for-installing-with-virtual-media_{context}']
 = Firmware requirements for installing with virtual media
 
diff --git a/modules/ipi-install-following-the-installation.adoc b/modules/ipi-install-following-the-installation.adoc
@@ -1,8 +1,9 @@
 // Module included in the following assemblies:
-// //installing/installing_bare_metal_ipi/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc
+//
+//installing/installing_bare_metal_ipi/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc
 
+:_content-type: PROCEDURE
 [id="ipi-install-troubleshooting-following-the-installation_{context}"]
-
 = Following the installation
 
 During the deployment process, you can check the installation's overall status by issuing the `tail` command to the `.openshift_install.log` log file in the install directory folder.
diff --git a/modules/ipi-install-installing-rhel-on-the-provisioner-node.adoc b/modules/ipi-install-installing-rhel-on-the-provisioner-node.adoc
@@ -2,6 +2,8 @@
 //
 // * list of assemblies where this module is included
 // ipi-install-installation-workflow.adoc
+
+:_content-type: PROCEDURE
 [id="installing-rhel-on-the-provisioner-node_{context}"]
 = Installing {op-system-base} on the provisioner node
 
diff --git a/modules/ipi-install-ipv6-network-requirements.adoc b/modules/ipi-install-ipv6-network-requirements.adoc
@@ -1,8 +1,9 @@
 // This is included in the following assemblies:
 //
 // ipi-install-prerequisites.adoc
-[id="ipi-install-ipv6-network-requirements_{context}"]
 
+:_content-type: CONCEPT
+[id="ipi-install-ipv6-network-requirements_{context}"]
 = IPv6 Network Requirements
 
 .SLAAC addressing
diff --git a/modules/ipi-install-modifying-install-config-for-dual-stack-network.adoc b/modules/ipi-install-modifying-install-config-for-dual-stack-network.adoc
@@ -2,6 +2,7 @@
 //
 // ipi-install-configuration-files.adoc
 
+:_content-type: PROCEDURE
 [id='modifying-install-config-for-dual-stack-network_{context}']
 = (Optional) Modifying the `install-config.yaml` file for dual-stack network
 
diff --git a/modules/ipi-install-modifying-install-config-for-no-provisioning-network.adoc b/modules/ipi-install-modifying-install-config-for-no-provisioning-network.adoc
@@ -2,6 +2,7 @@
 //
 // ipi-install-configuration-files.adoc
 
+:_content-type: PROCEDURE
 [id='modifying-install-config-for-no-provisioning-network_{context}']
 = (Optional) Modifying the `install-config.yaml` file for no `provisioning` network
 
diff --git a/modules/ipi-install-network-requirements.adoc b/modules/ipi-install-network-requirements.adoc
@@ -2,6 +2,7 @@
 //
 // * installing/installing_bare_metal_ipi/ipi-install-prerequisites.adoc
 
+:_content-type: CONCEPT
 [id='network-requirements_{context}']
 = Network requirements
 
@@ -154,4 +155,4 @@ You can reconfigure the control plane nodes to act as NTP servers on disconnecte
 [id='network-requirements-out-of-band_{context}']
 == Port access for the out-of-band management IP address
 
-The out-of-band management IP address is on a separate network from the node. To ensure that the out-of-band management can communicate with the `baremetal` node during installation, the out-of-band management IP address must be granted access to port `6180`.
+The out-of-band management IP address is on a separate network from the node. To ensure that the out-of-band management can communicate with the `baremetal` node during installation, the out-of-band management IP address must be granted access to port `6180`.
diff --git a/modules/ipi-install-node-requirements.adoc b/modules/ipi-install-node-requirements.adoc
@@ -2,6 +2,7 @@
 //
 // * installing/installing_bare_metal_ipi/ipi-install-prerequisites.adoc
 
+:_content-type: CONCEPT
 [id="node-requirements_{context}"'"]
 = Node requirements
 
diff --git a/modules/ipi-install-out-of-band-management.adoc b/modules/ipi-install-out-of-band-management.adoc
@@ -2,7 +2,7 @@
 //
 // * installing/installing_bare_metal_ipi/ipi-install-prerequisites.adoc
 
-
+:_content-type: CONCEPT
 [id="out-of-band-management_{context}"]
 = Out-of-band management
 
diff --git a/modules/ipi-install-provisioning-the-bare-metal-node.adoc b/modules/ipi-install-provisioning-the-bare-metal-node.adoc
@@ -1,9 +1,9 @@
 // This is included in the following assemblies:
 //
 // ipi-install-expanding-the-cluster.adoc
+
 :_content-type: PROCEDURE
 [id='provisioning-the-bare-metal-node_{context}']
-
 = Provisioning the bare metal node
 
 Provisioning the bare metal node requires executing the following procedure from the provisioner node.
@@ -117,4 +117,4 @@ $ ssh openshift-worker-<num>
 [source,terminal]
 ----
 [kni@openshift-worker-<num>]$ journalctl -fu kubelet
-----
+----
diff --git a/modules/ipi-install-required-data-for-installation.adoc b/modules/ipi-install-required-data-for-installation.adoc
@@ -2,6 +2,7 @@
 //
 // * installing/installing_bare_metal_ipi/ipi-install-prerequisites.adoc
 
+:_content-type: CONCEPT
 [id="required-data-for-installation_{context}"]
 = Required data for installation
 
diff --git a/modules/ipi-install-retrieving-the-openshift-installer.adoc b/modules/ipi-install-retrieving-the-openshift-installer.adoc
@@ -2,7 +2,7 @@
 //
 // * installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc
 
-
+:_content-type: PROCEDURE
 [id="retrieving-the-openshift-installer_{context}"]
 = Retrieving the {product-title} installer
 
diff --git a/modules/ipi-install-root-device-hints.adoc b/modules/ipi-install-root-device-hints.adoc
@@ -2,8 +2,8 @@
 //
 // ipi-install-configuration-files.adoc
 
+:_content-type: REFERENCE
 [id='root-device-hints_{context}']
-
 = 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.
diff --git a/modules/ipi-install-setting-proxy-settings-within-install-config.adoc b/modules/ipi-install-setting-proxy-settings-within-install-config.adoc
@@ -2,6 +2,7 @@
 //
 // ipi-install-configuration-files.adoc
 
+:_content-type: PROCEDURE
 [id='ipi-install-setting-proxy-settings-within-install-config_{context}']
 = (Optional) Setting proxy settings within the `install-config.yaml` file
 
