OSDOCS-9598: pre-pub 4.16 MicroShift nits

Author: ShaunaDiaz

microshift_configuring/microshift-audit-logs-config.adoc

@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="microshift-audit-logs-config"]
-= Customizing audit logging policies
+= Configuring audit logging policies
 include::_attributes/attributes-microshift.adoc[]
 :context: microshift-audit-logs-config
 

microshift_configuring/microshift-custom-ca.adoc

@@ -22,6 +22,6 @@ include::modules/microshift-custom-ca-troubleshooting.adoc[leveloffset=+1]
 
 * link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/securing_networks/creating-and-managing-tls-keys-and-certificates_securing-networks#doc-wrapper[RHEL: Creating and managing TLS keys and certificates]
 
-* link:https://access.redhat.com/documentation/en-us/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] for details.
+* link:https://access.redhat.com/documentation/en-us/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]
 
 * link:https://docs.openshift.com/container-platform/{ocp-version}/cli_reference/openshift_cli/managing-cli-profiles.html[OpenShift CLI Reference: oc login]

microshift_install/microshift-greenboot.adoc

@@ -8,7 +8,7 @@ toc::[]
 
 Greenboot is the generic health check framework for the `systemd` service on `rpm-ostree` systems such as {op-system-ostree-first}. This framework is included in {microshift-short} installations with the `microshift-greenboot` and `greenboot-default-health-checks` RPM packages.
 
-Greenboot health checks run at various times to assess system health and automate a rollback to the last healthy state in the event of software trouble, for example:
+Greenboot health checks run at various times to assess system health and automate a rollback on `rpm-ostree` systems to the last healthy state in cases of software trouble, for example:
 
 * Default health check scripts run each time the system starts.
 * In addition the to the default health checks, you can write, install, and configure application health check scripts to also run every time the system starts.
@@ -17,11 +17,6 @@ Greenboot health checks run at various times to assess system health and automat
 
 A {microshift-short} application health check script is included in the `microshift-greenboot` RPM. The `greenboot-default-health-checks` RPM includes health check scripts verifying that DNS and `ostree` services are accessible. You can create your own health check scripts for the workloads you are running. You can write one that verifies that an application has started, for example.
 
-[NOTE]
-====
-Rollback is not possible in the case of an update failure on a system not using `rpm-ostree`. This is true even though health checks might run.
-====
-
 include::modules/microshift-greenboot-dir-structure.adoc[leveloffset=+1]
 
 include::modules/microshift-greenboot-microshift-health-script.adoc[leveloffset=+1]

microshift_networking/microshift_multiple_networks/microshift-cni-multus.adoc

@@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[]
 
 toc::[]
 
-In addition to the default OVN-Kubernetes Container Network Interface (CNI) plugin, {microshift-short} uses an implementation of the Multus CNI to chain other CNI plugins.
+In addition to the default OVN-Kubernetes Container Network Interface (CNI) plugin, the {microshift-short} Multus CNI is available to chain other CNI plugins. Installing and using {microshift-short} Multus is optional.
 
 include::modules/microshift-multus-intro.adoc[leveloffset=+1]
 

microshift_running_apps/microshift-gitops.adoc

@@ -30,21 +30,21 @@ include::modules/microshift-gitops-adding-apps.adoc[leveloffset=+1]
 GitOps with Argo CD for {microshift-short} has the following differences from the Red Hat OpenShift GitOps Operator:
 
 * The `gitops-operator` component is not used with {microshift-short}.
-* To maintain the small resource use of {microshift-short}, the Argo CD web console is not available. You can use the Argo CD CLI or use a pull-based approach.
+* To maintain the small resource use of {microshift-short}, the Argo CD web console is not available. You can use the Argo CD CLI.
 * Because {microshift-short} is single-node, there is no multi-cluster support. Each instance of {microshift-short} is paired with a local GitOps agent.
 * The `oc adm must-gather` command is not available in {microshift-short}.
 
 [id="microshift-gitops-troubleshooting_{context}"]
 == Troubleshooting GitOps
-If you have problems with your GitOps controller, you can use either the {oc-first} tool or run an sos report.
+If you have problems with your GitOps controller, you can use the {oc-first} tool.
 
 include::modules/microshift-gitops-debug.adoc[leveloffset=+2]
 
-include::modules/microshift-gathering-sos-report.adoc[leveloffset=+2]
-
 [id="additional-resources_microshift-gitops_{context}"]
 [role="_additional-resources"]
 == Additional resources
+* xref:../microshift_install/microshift-install-rpm.adoc#microshift-installing-rpms-for-gitops_microshift-install-rpm[Installing the GitOps Argo CD manifests from an RPM package]
+
 * xref:../microshift_support/microshift-sos-report.adoc#microshift-sos-report[Using sos reports]
 
 * link:https://access.redhat.com/documentation/en-us/red_hat_openshift_gitops/1.12[Red Hat OpenShift GitOps]

microshift_troubleshooting/microshift-troubleshoot-backup-restore.adoc

@@ -21,7 +21,7 @@ Data backups are automatic on `rpm-ostree` systems. If you are not using an `rpm
 
 [id="troubleshoot-backup-restore-microshift-backup-logs_{context}"]
 == Backup logs
-* Logs print to the console during manual backups.
+* Logs print to the terminal console during manual backups.
 * Logs are automatically generated for `rpm-ostree` system automated backups as part of the {microshift-short} journal logs. You can check the logs by running the following command:
 +
 [source,terminal]

modules/microshift-custom-ca-con.adoc

@@ -41,5 +41,5 @@ If any validation fails, the {microshift-short} service skips the custom configu
 
 [IMPORTANT]
 ====
-Custom server certificates have to be validated against CA data configured in the trust root of the host operating system.
+Custom server certificates have to be validated against CA data configured in the trust root of the host operating system. For information, see link:https://access.redhat.com/documentation/en-us/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-gitops-adding-apps.adoc

@@ -8,51 +8,15 @@
 
 You can create a custom YAML configuration to deploy and manage applications in your {microshift-short} service. To install the necessary packages to run GitOps applications, follow the documentation in "Installing the GitOps Argo CD manifests from an RPM package".
 
-.Prerequisites 
+.Prerequisites
 
-* You installed the `microshift-gitops` packages and the Argo CD pods are running in the `openshift-gitops` namespace.
+* You installed the `microshift-gitops` packages.
 
-.Procedure 
+* The Argo CD pods are running in the `openshift-gitops` namespace.
 
-. Create a YAML file and add your customized configurations for the application: 
-+
-.Example YAML for a `cert-manager` application
-[source,yaml]
-----
-kind: AppProject
-apiVersion: argoproj.io/v1alpha1
-metadata:
-  name: default
-  namespace: openshift-gitops
-spec:
-  clusterResourceWhitelist:
-  - group: '*'
-    kind: '*'
-  destinations:
-  - namespace: '*'
-    server: '*'
-  sourceRepos:
-  - '*'
----
-apiVersion: argoproj.io/v1alpha1
-kind: Application
-metadata:
-  name: cert-manager
-  namespace: openshift-gitops
-spec:
-  destination:
-    namespace: cert-manager
-    server: https://kubernetes.default.svc
-  project: default
-  source:
-    path: cert-manager
-    repoURL: https://github.com/anandf/microshift-install
-  syncPolicy:
-    automated: {}
-    syncOptions:
-    - CreateNamespace=true
-    - ServerSideApply=true
-----
+.Procedure
+
+. Create a YAML file and add your customized configurations for the application:
 +
 .Example YAML for a `spring-petclinic` application
 [source,yaml]
@@ -98,10 +62,11 @@ spec:
 +
 [source,terminal]
 ----
-$ oc apply -f <filename>.yaml
+$ oc apply -f <my-app>.yaml <1>
 ----
+<1> Replace _<my-app>_ with the name of your application YAML.
 
-.Verification 
+.Verification
 
 * To verify your application is deployed and synced, run the following command:
 +
@@ -111,10 +76,9 @@ $ oc get applications -A
 ----
 It might take a few minutes for the application to show the `Healthy` status.
 +
-.Example output 
+.Example output
 [source,terminal]
 ----
 NAMESPACE          NAME               SYNC STATUS   HEALTH STATUS
-openshift-gitops   cert-manager       Synced        Healthy
 openshift-gitops   spring-petclinic   Synced        Healthy
 ----

modules/microshift-multus-intro.adoc

@@ -28,7 +28,7 @@ Setting network policies for additional networks is not supported.
 [id="microshift-additional-network-use-cases_{context}"]
 == Use case: Additional networks for network isolation
 
-You can use an additional network in situations where network isolation is needed, including control plane and data plane separation. You can create additional interfaces for pods to connect to that network in addition to a default. For example, you can configure an additional interface if you want pods to access a network on the host and also communicate with devices deployed to the edge. These edge devices might be on an isolated operator network or are periodically disconnected.
+You can use an additional network in situations where network isolation is needed, including control plane and data plane separation. For example, you can configure an additional interface if you want pods to access a network on the host and also communicate with devices deployed to the edge. These edge devices might be on an isolated operator network or are periodically disconnected.
 
 Isolating network traffic is useful for the following performance and security reasons:
 

modules/microshift-nw-multus-add-pod.adoc

@@ -28,7 +28,7 @@ apiVersion: v1
 kind: Pod
 metadata:
   annotations:
-    k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] <1>
+    k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] # <1>
 # ...
 ----
 <1> Replace `<network>` with the name of the additional network to associate with the pod. To specify more than one additional network, separate each network with a comma. Do not include whitespace between the comma. If you specify the same additional network multiple times, that pod will have multiple network interfaces attached to that network.
@@ -56,9 +56,9 @@ metadata:
     k8s.v1.cni.cncf.io/networks: |-
       [
         {
-          "name": "<network>", <1>
-          "namespace": "<namespace>", <2>
-          "default-route": ["<default-route>"] <3>
+          "name": "<network>", # <1>
+          "namespace": "<namespace>", # <2>
+          "default-route": ["<default-route>"] # <3>
         }
       ]
 # ...
@@ -151,7 +151,7 @@ kind: Pod
 metadata:
   annotations:
     k8s.v1.cni.cncf.io/networks: bridge-conf
-    k8s.v1.cni.cncf.io/network-status: |- <1>
+    k8s.v1.cni.cncf.io/network-status: |- # <1>
       [{
           "name": "ovn-kubernetes",
           "interface": "eth0",