[OSDOCS#21750] Fix MicroShift JTBD Vale errors

modules/microshift-about-remote-health-monitoring.adoc

@@ -13,7 +13,7 @@ Remote health monitoring is conducted in {microshift-short} by the collection of
 
 Telemetry provides the following benefits:
 
-* *Enhanced identification and resolution of issues*. Events that might seem normal to an end-user can be observed by Red{nbsp}Hat from a broader perspective. Some issues can be more rapidly identified from this point of view and resolved without an end-user needing to open a support case or file a link:https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Summary&issuetype=1&priority=10200&versions=12385624[Jira issue].
+* *Enhanced identification and resolution of issues*. Events that might seem normal to an end-user can be observed by Red{nbsp}Hat from a broader perspective. Some issues can be more rapidly identified from this point of view and resolved without an end-user needing to open a support case or file a Jira issue.
 
 * *Targeted prioritization of new features and functionality*. The data collected provides information about system capabilities and usage characteristics. With this information, Red{nbsp}Hat can focus on developing the new features and functionality that have the greatest impact for our customers.
 
@@ -24,4 +24,9 @@ This debugging information is available to Red{nbsp}Hat Support and Engineering
 [NOTE]
 ====
 {microshift-short} does not support Prometheus. To view the Telemetry gathered from your node, you must contact Red{nbsp}Hat Support.
-====
+====
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Summary&issuetype=1&priority=10200&versions=12385624[Open a Jira issue]

modules/microshift-applying-manifests-example.adoc

@@ -28,7 +28,7 @@ $ sudo mkdir -p ${MANIFEST_DIR}
 +
 .. Place the YAML file in the directory:
 +
-[source,text]
+[source,text,subs="verbatim"]
 ----
 sudo tee ${MANIFEST_DIR}/busybox.yaml &>/dev/null <<EOF
 apiVersion: v1
@@ -61,7 +61,7 @@ EOF
 +
 .. Place the YAML file in the directory:
 +
-[source,text]
+[source,text,subs="verbatim"]
 ----
 sudo tee ${MANIFEST_DIR}/kustomization.yaml &>/dev/null <<EOF
 apiVersion: kustomize.config.k8s.io/v1beta1

modules/microshift-custom-ca-con.adoc

@@ -37,13 +37,16 @@ In most cases, {microshift-short} generates a new `kubeconfig` file for your cus
 +
 [IMPORTANT]
 ====
-Custom server certificates must be validated against CA data configured in the trust root of the host operating system. For more information, read the following documentation:
-
-* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/securing_networks/using-shared-system-certificates_securing-networks#the-system-wide-trust-store_using-shared-system-certificates[The system-wide truststore]
+Custom server certificates must be validated against CA data configured in the trust root of the host operating system. For more information, see "The system-wide truststore".
 ====
 
 . The certificates and keys are read from the specified file location on the host. You can test and validate configuration from the client.
 
 * If any validation fails, {microshift-short} skips the custom configuration and uses the default certificate to start. The priority is to continue the service uninterrupted. {microshift-short} logs errors when the service starts. Common errors include expired certificates, missing files, or wrong IP addresses.
 
 . External server certificates are not automatically renewed. You must manually rotate your external certificates.
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/securing_networks/using-shared-system-certificates_securing-networks#the-system-wide-trust-store_using-shared-system-certificates[The system-wide truststore]

modules/microshift-embed-app-rpms-tutorial.adoc

@@ -17,7 +17,6 @@ Embedding applications requires a similar workflow to embedding {microshift-shor
 * The ostree commit then can follow either the ISO path or the repository path to edge devices.
 * The ISO path can be used for disconnected environments, while the repository path is often used in places were the network is usually connected.
 
-.Embedding {microshift-short} workflow
 image:468_RHbM_install_workflow_1023_1.png[title="Embedding MicroShift in a RHEL for Edge image workflow."]
 
 Reviewing these steps can help you understand the steps needed to embed an application:
@@ -28,7 +27,7 @@ Reviewing these steps can help you understand the steps needed to embed an appli
 
 . You added the blueprint to image builder and ran a build with the image builder CLI tool (`composer-cli`). This step created `rpm-ostree` commits, which were used to create the container image. This image contained {op-system-ostree}.
 
-. You added the installer blueprint to image builder to create an `rpm-ostree` image (ISO) to boot from. This build contained both {op-system-ostree} and {microshift-short}.
+. You added the blueprint for the installation ISO to image builder to create an `rpm-ostree` image (ISO) to boot from. This build contained both {op-system-ostree} and {microshift-short}.
 
 . You downloaded the ISO with {microshift-short} embedded, prepared it for use, provisioned it, then installed it onto your edge devices.
 
@@ -39,7 +38,6 @@ After you have set up a build host that meets the image builder requirements, yo
 
 The following "Embedding applications workflow" image shows how Kubernetes application manifests and RPM spec files are combined in a single application RPM build. This build becomes the RPM artifact included in the workflow for embedding {microshift-short} in an ostree commit.
 
-.Embedding applications workflow
 image:468_RHbM_install_workflow_1023_2.png[title="Embedding applications workflow."]
 
 The following procedures use the `rpmbuild` tool to create a specification file and local repository. The specification file defines how the package is built, moving your application manifests to the correct location inside the RPM package for {microshift-short} to pick them up. That RPM package is then embedded in the ISO.

modules/microshift-embed-images-offline-use.adoc

@@ -37,7 +37,7 @@ $ sudo composer-cli blueprints push _<my_blueprint>_.toml
 
 .. If needed, create a directory and file for the pull secret, for example:
 +
-.Example directory and file
+The directory and file can look like the following example:
 +
 [source,terminal,subs="+quotes"]
 ----

modules/microshift-enabling-workload-partitioning.adoc

@@ -6,6 +6,7 @@
 [id="microshift-enabling-workload-partitioning_{context}"]
 = Enable workload partitioning
 
+[role="_abstract"]
 To enable workload partitioning on {microshift-short}, make the following configuration changes:
 
 * Update the {microshift-short} `config.yaml` file to include the kubelet configuration file.
@@ -23,28 +24,34 @@ To enable workload partitioning on {microshift-short}, make the following config
 # ...
 {
   "management": {
-    "cpuset": "0,6,7" <1>
+    "cpuset": "0,6,7"
   }
 }
 # ...
 ----
-<1> The `cpuset` applies to a machine with 8 VCPUs (4 cores) and is valid throughout the document.
++
+where:
++
+`cpuset`:: The `cpuset` applies to a machine with 8 VCPUs (4 cores) and is valid throughout the document.
 * Update the {microshift-short} config.yaml file in the path `/etc/microshift/config.yaml`. Embed the kubelet configuration in the {microshift-short} `config.yaml` file to enable and configure CPU Manager for the workloads.
 +
 .{microshift-short} `config.yaml` example
 [source,yaml]
 ----
 # ...
 kubelet:
-  reservedSystemCPUs: 0,6,7 <1>
+  reservedSystemCPUs: 0,6,7
   cpuManagerPolicy: static
   cpuManagerPolicyOptions:
-    full-pcpus-only: "true" <2>
+    full-pcpus-only: "true"
   cpuManagerReconcilePeriod: 5s
 # ...
 ----
-<1> Exclusive cpuset for the system daemons and the interrupts/timers.
-<2> kubelet configuration sets the `CPUManagerPolicyOptions` option to `full-pcpus-only` to ensure allocation of whole cores to the containers workload.
++
+where:
++
+`reservedSystemCPUs`:: Exclusive cpuset for the system daemons and the interrupts/timers.
+`full-pcpus-only`:: The kubelet configuration sets the `CPUManagerPolicyOptions` option to `full-pcpus-only` to ensure allocation of whole cores to the containers workload.
 
 . Create the CRI-O systemd and configuration files:
 * Create the CRI-O configuration file in the path `/etc/crio/crio.conf.d/20-microshift-workload-partition.conf` which overrides the default configuration that already exists in the `11-microshift-ovn.conf` file.

modules/microshift-get-node-id-kubesystem.adoc

@@ -17,7 +17,8 @@ Retrieving the node ID enables you to uniquely identify a device within your dep
 ----
 $ oc get namespaces kube-system -o jsonpath={.metadata.uid}
 ----
-.Example output
++
+Example output:
 +
 [source,terminal]
 ----
@@ -30,7 +31,8 @@ $ oc get namespaces kube-system -o jsonpath={.metadata.uid}
 ----
 $ sudo cat /var/lib/microshift/cluster-id
 ----
-.Example output
++
+Example output:
 +
 [source,terminal]
 ----

modules/microshift-get-nonrunning-node-id-kubesystem.adoc

@@ -6,6 +6,7 @@
 [id="microshift-get-nonrunning-node-id-kubesystem_{context}"]
 = Get the node ID of a stopped node
 
+[role="_abstract"]
 When the MicroShift service is inactive, you can prevent the use of standard API commands by retrieving the node ID from the file system. You can use this ID to identify offline nodes for disaster recovery, verify backup compatibility, and troubleshoot issues.
 
 .Procedure
@@ -16,7 +17,8 @@ When the MicroShift service is inactive, you can prevent the use of standard API
 ----
 $ sudo cat /var/lib/microshift/cluster-id
 ----
-.Example output
++
+Example output:
 +
 [source,terminal]
 ----

modules/microshift-greenboot-systemd-journal-data.adoc

@@ -20,7 +20,7 @@ $ sudo mkdir -p /etc/systemd/journald.conf.d
 
 . Create the configuration file by running the following command:
 +
-[source,terminal]
+[source,terminal,subs="verbatim"]
 ----
 cat <<EOF | sudo tee /etc/systemd/journald.conf.d/microshift.conf &>/dev/null
 [Journal]

modules/microshift-install-cert-manager-olm.adoc

@@ -7,4 +7,10 @@
 = Install and enable the cert-manager Operator using OLM
 
 [role="_abstract"]
-You can install the optional `microshift-cert-manager` by using OLM at any time. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/{ocp-version}/html/running_applications/operators#microshift-operators-olm[Using Operator Lifecycle Manager with MicroShift] and link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html/security_and_compliance/cert-manager-operator-for-red-hat-openshift#cert-manager-operator-install[Installing the cert-manager Operator for Red Hat OpenShift].
+You can install the optional `microshift-cert-manager` by using OLM at any time.
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/{ocp-version}/html/running_applications/operators#microshift-operators-olm[Using Operator Lifecycle Manager with MicroShift]
+* link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html/security_and_compliance/cert-manager-operator-for-red-hat-openshift#cert-manager-operator-install[Installing the {cert-manager-operator}]

modules/microshift-install-multus-running-node.adoc

@@ -2,7 +2,7 @@
 //
 // * microshift_networking/microshift-cni-multus.adoc
 
-:_mod-docs-content-type: CONCEPT
+:_mod-docs-content-type: PROCEDURE
 [id="microshift-multus-installing-on-running-node_{context}"]
 = Install the Multus CNI plugin on a running node
 

modules/microshift-install-rhde-steps.adoc

@@ -11,21 +11,21 @@ Before proceeding with your specific installation method, you must prepare your
 
 For most installation types, you must also take the following steps:
 
-* Download the pull secret from the Red{nbsp}Hat Hybrid Cloud Console using the following link:
-
-** link:https://console.redhat.com/openshift/install/pull-secret[Pull secret]
+* Download the pull secret.
 
 * Be ready to configure {microshift-short} by adding parameters and values to the {microshift-short} YAML configuration file. For more information, see "Customizing MicroShift by using the configuration file".
 
 * Decide whether you need to configure storage for the application and tasks you are using in your {microshift-short} node, or disable the {microshift-short} storage plugin completely.
 
-* For more information about creating volume groups and persistent volumes on {op-system-base}, see the following link:
-
-** link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/overview-of-logical-volume-management_configuring-and-managing-logical-volumes[Overview of logical volume management]
-
 * Configure networking settings according to the access needs you plan for your {microshift-short} node and applications. Consider whether you want to use single or dual-stack networks, configure a firewall, or configure routes.
 +
 [NOTE]
 ====
 You can use the {op-system-rt-kernel} where predictable latency is critical. Workload partitioning is also required for low-latency applications. For more information about low latency and the {op-system-rtk}, see "Configuring low latency".
 ====
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://console.redhat.com/openshift/install/pull-secret[Pull secret]
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/overview-of-logical-volume-management_configuring-and-managing-logical-volumes[Overview of logical volume management]