OSDOCS-14447: Installing recs visibility

skopacz1 · skopacz1 · commit 58ff0b77b47e · 2025-04-29T15:42:05.000-04:00
diff --git a/disconnected/mirroring/about-installing-oc-mirror-v2.adoc b/disconnected/mirroring/about-installing-oc-mirror-v2.adoc
@@ -82,8 +82,7 @@ After your cluster is configured to use the resources generated by oc-mirror plu
 
 * xref:../../extensions/catalogs/disconnected-catalogs.adoc#disconnected-catalogs[Disconnected environment support in {olmv1}]
 
-// Delete Feature
-// workflows of delete feature
+// Deletion of images from your disconnected environment
 include::modules/oc-mirror-workflows-delete-v2.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
@@ -92,7 +91,7 @@ include::modules/oc-mirror-workflows-delete-v2.adoc[leveloffset=+1]
 
 include::modules/oc-mirror-v2-procedure-garbage-collector.adoc[leveloffset=+2]
 
-// procedure for delete feature
+// Deleting images from a disconnected environment
 include::modules/oc-mirror-procedure-delete-v2.adoc[leveloffset=+2]
 
 // About dry-run
@@ -101,13 +100,13 @@ include::modules/oc-mirror-v2-about-dry-run.adoc[leveloffset=+1]
 // Performing Dry-run for V2
 include::modules/oc-mirror-dry-run-v2.adoc[leveloffset=+2]
 
-// Troubleshooting
+// Troubleshooting oc-mirror plugin v2 errors
 include::modules/oc-mirror-troubleshooting-v2.adoc[leveloffset=+1]
 
-// oc-mirror-enclave-support-about
+// Benefits of enclave support
 include::modules//oc-mirror-enclave-support-about.adoc[leveloffset=+1]
 
-// How to mirror to an Enclave
+// Mirroring to an enclave
 include::modules/oc-mirror-enclave-support.adoc[leveloffset=+2]
 
 // Proxy support
diff --git a/disconnected/mirroring/installing-mirroring-creating-registry.adoc b/disconnected/mirroring/installing-mirroring-creating-registry.adoc
@@ -20,15 +20,17 @@ The _mirror registry for Red Hat OpenShift_ is not intended to be a substitute f
 
 * An {product-title} subscription.
 * {op-system-base-full} 8 and 9 with Podman 3.4.2 or later and OpenSSL installed.
-* Fully qualified domain name for the Red Hat Quay service, which must resolve through a DNS server.
+* Fully qualified domain name for the Red{nbsp}Hat Quay service, which must resolve through a DNS server.
 * Key-based SSH connectivity on the target host. SSH keys are automatically generated for local installs. For remote hosts, you must generate your own SSH keys.
 * 2 or more vCPUs.
 * 8 GB of RAM.
-* About 12 GB for {product-title} {product-version} release images, or about 358 GB for {product-title} {product-version} release images and {product-title} {product-version} Red Hat Operator images. Up to 1 TB per stream or more is suggested.
+* About 12 GB for {product-title} {product-version} release images, or about 358 GB for {product-title} {product-version} release images and {product-title} {product-version} Red{nbsp}Hat Operator images.
 +
 [IMPORTANT]
 ====
-These requirements are based on local testing results with only release images and Operator images. Storage requirements can vary based on your organization's needs. You might require more space, for example, when you mirror multiple z-streams. You can use standard link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html/use_red_hat_quay/index[Red Hat Quay functionality] or the proper link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/red_hat_quay_api_guide/index#deletefulltag[API callout] to remove unnecessary images and free up space.
+* Up to 1 TB per stream or more is suggested.
+
+* These requirements are based on local testing results with only release images and Operator images. Storage requirements can vary based on your organization's needs. You might require more space, for example, when you mirror multiple z-streams. You can use standard link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html/use_red_hat_quay/index[Red{nbsp}Hat Quay functionality] or the proper link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/red_hat_quay_api_guide/index#deletefulltag[API callout] to remove unnecessary images and free up space.
 ====
 
 include::modules/mirror-registry-introduction.adoc[leveloffset=+1]
diff --git a/modules/agent-install-ipi-install-root-device-hints.adoc b/modules/agent-install-ipi-install-root-device-hints.adoc
@@ -10,11 +10,17 @@ The `rootDeviceHints` parameter enables the installer to provision the {op-syste
 
 .Subfields
 
-[cols="1,3"]
+[cols="1,3a"]
 |===
 | Subfield | Description
 
-| `deviceName` | A string containing a Linux device name such as `/dev/vda` or `/dev/disk/by-path/`. It is recommended to use the `/dev/disk/by-path/<device_path>` link to the storage location. The hint must match the actual value exactly.
+| `deviceName` | A string containing a Linux device name such as `/dev/vda` or `/dev/disk/by-path/`.
+[NOTE]
+====
+It is recommended to use the `/dev/disk/by-path/<device_path>` link to the storage location.
+====
+
+The hint must match the actual value exactly.
 
 | `hctl` | A string containing a SCSI bus address like `0:0:0:0`. The hint must match the actual value exactly.
 
diff --git a/modules/cluster-bare-metal-operator.adoc b/modules/cluster-bare-metal-operator.adoc
@@ -39,12 +39,15 @@ The Cluster Baremetal Operator (CBO) deploys all the components necessary to tak
 ifdef::cluster-caps[]
 The bare-metal capability is required for deployments using installer-provisioned infrastructure. Disabling the bare-metal capability can result in unexpected problems with these deployments.
 
-It is recommended that cluster administrators only disable the bare-metal capability during installations with user-provisioned infrastructure that do not have any `BareMetalHost` resources in the cluster.
-
 [IMPORTANT]
 ====
 If the bare-metal capability is disabled, the cluster cannot provision or manage bare-metal nodes. Only disable the capability if there are no `BareMetalHost` resources in your deployment. The `baremetal` capability depends on the `MachineAPI` capability. If you enable the `baremetal` capability, you must also enable `MachineAPI`.
 ====
+
+[NOTE]
+====
+It is recommended that cluster administrators only disable the bare-metal capability during installations with user-provisioned infrastructure that do not have any `BareMetalHost` resources in the cluster.
+====
 endif::cluster-caps[]
 
 ifdef::operator-ref[]
diff --git a/modules/installation-aws-iam-user.adoc b/modules/installation-aws-iam-user.adoc
@@ -6,11 +6,12 @@
 [id="installation-aws-iam-user_{context}"]
 = Creating an IAM user
 
-Each Amazon Web Services (AWS) account contains a root user account that is
-based on the email address you used to create the account. This is a
-highly-privileged account, and it is recommended to use it for only initial
-account and billing configuration, creating an initial set of users, and
-securing the account.
+Each Amazon Web Services (AWS) account contains a root user account that is based on the email address you used to create the account.
+
+[IMPORTANT]
+====
+This is a highly-privileged account, and it is recommended to use it for only initial account and billing configuration, creating an initial set of users, and securing the account.
+====
 
 Before you install {product-title}, create a secondary IAM
 administrative user. As you complete the
diff --git a/modules/installation-azure-limits.adoc b/modules/installation-azure-limits.adoc
@@ -117,7 +117,11 @@ ifndef::ash[]
 |OS Disk
 |7
 |
-|Each cluster machine must have a minimum of 100 GB of storage and 300 IOPS. While these are the minimum supported values, faster storage is recommended for production clusters and clusters with intensive workloads. For more information about optimizing storage for performance, see the page titled "Optimizing storage" in the "Scalability and performance" section.
+|Each cluster machine must have a minimum of 100 GB of storage and 300 IOPS.
+[NOTE]
+====
+Faster storage is recommended for production clusters and clusters with intensive workloads. For more information about optimizing storage for performance, see the page titled "Optimizing storage" in the "Scalability and performance" section.
+====
 endif::ash[]
 
 |VNet
diff --git a/modules/installation-ibm-cloud-iam-policies-api-key.adoc b/modules/installation-ibm-cloud-iam-policies-api-key.adoc
@@ -153,7 +153,10 @@ endif::ibm-power-vs[]
 * Service ID
 * User
 
+[NOTE]
+====
 The recommended method is to define IAM access policies in an link:https://cloud.ibm.com/docs/account?topic=account-groups[access group]. This helps organize all the access required for {product-title} and enables you to onboard users and service IDs to this group. You can also assign access to link:https://cloud.ibm.com/docs/account?topic=account-assign-access-resources[users and service IDs] directly, if desired.
+====
 
 ifeval::["{context}" == "installing-ibm-cloud-account"]
 :!ibm-vpc:
diff --git a/modules/installation-network-user-infra.adoc b/modules/installation-network-user-infra.adoc
@@ -87,11 +87,11 @@ endif::ibm-z[]
 ifndef::ibm-z[]
 During the initial boot, the machines require an IP address configuration that is set either through a DHCP server or statically by providing the required boot options. After a network connection is established, the machines download their Ignition config files from an HTTP or HTTPS server. The Ignition config files are then used to set the exact state of each machine. The Machine Config Operator completes more changes to the machines, such as the application of new certificates or keys, after installation.
 
-It is recommended to use a DHCP server for long-term management of the cluster machines. Ensure that the DHCP server is configured to provide persistent IP addresses, DNS server information, and hostnames to the cluster machines.
-
 [NOTE]
 ====
-If a DHCP service is not available for your user-provisioned infrastructure, you can instead provide the IP networking configuration and the address of the DNS server to the nodes at {op-system} install time. These can be passed as boot arguments if you are installing from an ISO image. See the _Installing {op-system} and starting the {product-title} bootstrap process_ section for more information about static IP provisioning and advanced networking options.
+* It is recommended to use a DHCP server for long-term management of the cluster machines. Ensure that the DHCP server is configured to provide persistent IP addresses, DNS server information, and hostnames to the cluster machines.
+
+* If a DHCP service is not available for your user-provisioned infrastructure, you can instead provide the IP networking configuration and the address of the DNS server to the nodes at {op-system} install time. These can be passed as boot arguments if you are installing from an ISO image. See the _Installing {op-system} and starting the {product-title} bootstrap process_ section for more information about static IP provisioning and advanced networking options.
 ====
 endif::ibm-z[]
 
diff --git a/modules/installation-user-infra-machines-static-network.adoc b/modules/installation-user-infra-machines-static-network.adoc
@@ -584,7 +584,12 @@ The following table shows the {op-system} live installer `coreos.inst` boot opti
 
 a|`coreos.inst.install_dev`
 
-a|Required. The block device on the system to install to. It is recommended to use the full path, such as `/dev/sda`, although `sda` is allowed.
+a|Required. The block device on the system to install to.
+
+[NOTE]
+====
+It is recommended to use the full path, such as `/dev/sda`, although `sda` is allowed.
+====
 
 a|`coreos.inst.ignition_url`
 
diff --git a/modules/ipi-install-root-device-hints.adoc b/modules/ipi-install-root-device-hints.adoc
@@ -13,7 +13,13 @@ The `rootDeviceHints` parameter enables the installer to provision the {op-syste
 |===
 | Subfield | Description
 
-| `deviceName` | A string containing a Linux device name such as `/dev/vda` or `/dev/disk/by-path/`. It is recommended to use the `/dev/disk/by-path/<device_path>` link to the storage location. The hint must match the actual value exactly.
+| `deviceName` a| A string containing a Linux device name such as `/dev/vda` or `/dev/disk/by-path/`.
+[NOTE]
+====
+It is recommended to use the `/dev/disk/by-path/<device_path>` link to the storage location.
+====
+
+The hint must match the actual value exactly.
 
 | `hctl` | A string containing a SCSI bus address like `0:0:0:0`. The hint must match the actual value exactly.
 
diff --git a/modules/oc-mirror-command-reference.adoc b/modules/oc-mirror-command-reference.adoc
@@ -36,7 +36,7 @@ The following tables describe the `oc mirror` subcommands and flags:
 |===
 
 .oc mirror flags
-[cols="1,2",options="header"]
+[cols="1,2a",options="header"]
 |===
 |Flag
 |Description
@@ -87,7 +87,11 @@ The following tables describe the `oc mirror` subcommands and flags:
 |Do not replace image tags with digest pins in Operator catalogs.
 
 |`--skip-metadata-check`
-|Skip metadata when publishing an image set. This is only recommended when the image set was created with `--ignore-history`.
+|Skip metadata when publishing an image set.
+[NOTE]
+====
+This is recommended only when the image set was created with the `--ignore-history` flag.
+====
 
 |`--skip-missing`
 |If an image is not found, skip it instead of reporting an error and aborting execution. Does not apply to custom images explicitly specified in the image set configuration.
