Merge pull request #48167 from rh-tokeefe/OSSMDOC-360

OSSMDOC-360: Updated workarounds to match style standard

Author: JStickler

modules/distr-tracing-rn-fixed-issues.adoc

@@ -39,4 +39,6 @@ This issue was resolved by exposing only the HTTP(S) port of the query service,
 
 * link:https://issues.redhat.com/browse/TRACING-809[TRACING-809] Jaeger Ingester is incompatible with Kafka 2.3. When there are two or more instances of the Jaeger Ingester and enough traffic it will continuously generate rebalancing messages in the logs. This is due to a regression in Kafka 2.3 that was fixed in Kafka 2.3.1. For more information, see https://github.com/jaegertracing/jaeger/issues/1819[Jaegertracing-1819].
 
-* link:https://bugzilla.redhat.com/show_bug.cgi?id=1918920[BZ-1918920]/link:https://issues.redhat.com/browse/LOG-1619[LOG-1619] The Elasticsearch pods does not get restarted automatically after an update. As a workaround, restart the pods manually.
+* link:https://bugzilla.redhat.com/show_bug.cgi?id=1918920[BZ-1918920]/link:https://issues.redhat.com/browse/LOG-1619[LOG-1619] The Elasticsearch pods does not get restarted automatically after an update.
++
+Workaround: Restart the pods manually.

modules/ossm-rn-fixed-issues.adoc

@@ -58,7 +58,9 @@ Namespace starting with `kube` is hidden from Kiali.
 
 * link:https://issues.redhat.com/browse/OSSM-287[OSSM-287] In the Kiali console there are no traces being displayed on the Graph Service.
 
-* link:https://issues.redhat.com/browse/OSSM-285[OSSM-285] When trying to access the Kiali console, receive the following error message "Error trying to get OAuth Metadata". The workaround is to restart the Kiali pod.
+* link:https://issues.redhat.com/browse/OSSM-285[OSSM-285] When trying to access the Kiali console, receive the following error message "Error trying to get OAuth Metadata".
++
+Workaround: Restart the Kiali pod.
 
 * link:https://issues.redhat.com/browse/MAISTRA-2735[MAISTRA-2735] The resources that the Service Mesh Operator deletes when reconciling the SMCP changed in {SMProductName} version 2.1. Previously, the Operator deleted a resource with the following labels:
 
@@ -77,7 +79,9 @@ Now, the Operator ignores resources that does not also include the `app.kubernet
 
 * link:https://issues.redhat.com/browse/MAISTRA-2534[MAISTRA-2534] When istiod attempted to fetch the JWKS for an issuer specified in a JWT rule, the issuer service responded with a 502.  This prevented the proxy container from becoming ready and caused deployments to hang. The fix for the link:https://github.com/istio/istio/issues/24629[community bug] has been included in the  {SMProductShortName} 2.0.7 release.
 
-* link:https://issues.jboss.org/browse/MAISTRA-2411[MAISTRA-2411] When the Operator creates a new ingress gateway using `spec.gateways.additionaIngress` in the `ServiceMeshControlPlane`, Operator is not creating a `NetworkPolicy` for the additional ingress gateway like it does for the default istio-ingressgateway. This is causing a 503 response from the route of the new gateway. The workaround for this issue is to manually create the `NetworkPolicy` in the <istio-system> namespace.
+* link:https://issues.jboss.org/browse/MAISTRA-2411[MAISTRA-2411] When the Operator creates a new ingress gateway using `spec.gateways.additionaIngress` in the `ServiceMeshControlPlane`, Operator is not creating a `NetworkPolicy` for the additional ingress gateway like it does for the default istio-ingressgateway. This is causing a 503 response from the route of the new gateway.
++
+Workaround: Manually create the `NetworkPolicy` in the <istio-system> namespace.
 
 * link:https://issues.redhat.com/browse/MAISTRA-2401[MAISTRA-2401] CVE-2021-3586 servicemesh-operator: NetworkPolicy resources incorrectly specified ports for ingress resources. The NetworkPolicy resources installed for {SMProductName} did not properly specify which ports could be accessed. This allowed access to all ports on these resources from any pod. Network policies applied to the following resources are affected:
 
@@ -110,7 +114,9 @@ Upgrading the operator to 2.0 might break client tools that read the SMCP status
 +
 This also causes the READY and STATUS columns to be empty when you run `oc get servicemeshcontrolplanes.v1.maistra.io`.
 
-* link:https://issues.jboss.org/browse/MAISTRA-1947[MAISTRA-1947] _Technology Preview_ Updates to ServiceMeshExtensions are not applied. The workaround is to remove and recreate the ServiceMeshExtensions.
+* link:https://issues.jboss.org/browse/MAISTRA-1947[MAISTRA-1947] _Technology Preview_ Updates to ServiceMeshExtensions are not applied.
++
+Workaround: Remove and recreate the `ServiceMeshExtensions`.
 
 * link:https://issues.redhat.com/browse/MAISTRA-1983[MAISTRA-1983] _Migration to 2.0_ Upgrading to 2.0.0 with an existing invalid `ServiceMeshControlPlane` cannot easily be repaired. The invalid items in the `ServiceMeshControlPlane` resource caused an unrecoverable error. The fix makes the errors recoverable. You can delete the invalid resource and replace it with a new one or edit the resource to fix the errors. For more information about editing your resource, see [Configuring the Red Hat OpenShift Service Mesh installation].
 
@@ -127,8 +133,8 @@ This also causes the READY and STATUS columns to be empty when you run `oc get s
 
 * link:https://issues.jboss.org/browse/MAISTRA-806[MAISTRA-806] Evicted Istio Operator Pod causes mesh and CNI not to deploy.
 +
-If the `istio-operator` pod is evicted while deploying the control pane, delete the evicted `istio-operator` pod.
-+
+Workaround: If the `istio-operator` pod is evicted while deploying the control pane, delete the evicted `istio-operator` pod.
+
 * link:https://issues.jboss.org/browse/MAISTRA-681[MAISTRA-681] When the control plane has many namespaces, it can lead to performance issues.
 
 * link:https://issues.jboss.org/browse/MAISTRA-193[MAISTRA-193] Unexpected console info messages are visible when health checking is enabled for citadel.

modules/ossm-rn-known-issues-1x.adoc

@@ -26,7 +26,9 @@ These limitations exist in {SMProductName}:
 
 These are the known issues in {SMProductName}:
 
-* link:https://access.redhat.com/solutions/4970771[Jaeger/Kiali Operator upgrade blocked with operator pending] When upgrading the Jaeger or Kiali Operators with Service Mesh 1.0.x installed, the operator status shows as Pending. There is a solution in progress and a workaround. See the linked Knowledge Base article for more information.
+* link:https://access.redhat.com/solutions/4970771[Jaeger/Kiali Operator upgrade blocked with operator pending] When upgrading the Jaeger or Kiali Operators with Service Mesh 1.0.x installed, the operator status shows as Pending.
++
+Workaround: See the linked Knowledge Base article for more information.
 
 * link:https://github.com/istio/istio/issues/14743[Istio-14743] Due to limitations in the version of Istio that this release of {SMProductName} is based on, there are several applications that are currently incompatible with {SMProductShortName}. See the linked community issue for details.
 
@@ -37,7 +39,7 @@ These are the known issues in {SMProductName}:
 
 * link:https://issues.jboss.org/browse/MAISTRA-806[MAISTRA-806] Evicted Istio Operator Pod causes mesh and CNI not to deploy.
 +
-If the `istio-operator` pod is evicted while deploying the control pane, delete the evicted `istio-operator` pod.
+Workaround: If the `istio-operator` pod is evicted while deploying the control pane, delete the evicted `istio-operator` pod.
 +
 * link:https://issues.jboss.org/browse/MAISTRA-681[MAISTRA-681] When the control plane has many namespaces, it can lead to performance issues.
 

modules/ossm-rn-known-issues.adoc

@@ -43,13 +43,16 @@ After enabling the `spec.security.controlPlane.mtls` setting in the SMCP, the Ki
 
 * https://issues.redhat.com/browse/OSSM-1168[OSSM-1168] When service mesh resources are created as a single YAML file, the Envoy proxy sidecar is not reliably injected into pods. When the SMCP, SMMR, and Deployment resources are created individually, the deployment works as expected.
 //Keep OSSM-1052 in RN - Closed as documented.
-* https://issues.redhat.com/browse/OSSM-1052[OSSM-1052] When configuring a Service `ExternalIP` for the ingressgateway in the service mesh control plane, the service is not created. The schema for the SMCP is missing the parameter for the service. The workaround for this issue is to disable the gateway creation in the SMCP spec and manage the gateway deployment entirely manually (including Service, Role and RoleBinding).
+* https://issues.redhat.com/browse/OSSM-1052[OSSM-1052] When configuring a Service `ExternalIP` for the ingressgateway in the service mesh control plane, the service is not created. The schema for the SMCP is missing the parameter for the service.
++
+Workaround: Disable the gateway creation in the SMCP spec and manage the gateway deployment entirely manually (including Service, Role and RoleBinding).
+
 //Keep OSSM-882 in RN to document the workaround
 * https://issues.redhat.com/browse/OSSM-882[OSSM-882] Namespace is in the accessible_namespace list but does not appear in Kiali UI. By default, Kiali will not show any namespaces that start with "kube" because these namespaces are typically internal-use only and not part of a mesh.
 +
 For example, if you create a namespace called 'akube-a' and add it to the Service Mesh member roll, then the Kiali UI does not display the namespace. For defined exclusion patterns, the software excludes namespaces that start with or contain the pattern.
 +
-The workaround is to change the Kiali Custom Resource setting so it prefixes the setting with a carat (^). For example:
+Workaround: Change the Kiali Custom Resource setting so it prefixes the setting with a carat (^). For example:
 +
 [source,yaml]
 ----