Merge pull request #28109 from brian-avery/fixesOSSMDocs

Some fixes to the OSSM docs

Author: neal-timpe

modules/ossm-jaeger-service-mesh.adoc

@@ -11,7 +11,7 @@ Installing Jaeger with the Service Mesh on {product-title} differs from communit
 
 * Jaeger has been enabled by default for {ProductShortName}.
 * Ingress has been enabled by default for {ProductShortName}.
-* The name for the Zipkin port name has changed to jaeger-collector-zipkin (from http)
+* The name for the Zipkin port name has changed to `jaeger-collector-zipkin` (from `http`)
 * Jaeger uses Elasticsearch for storage by default.
 * The community version of Istio provides a generic "tracing" route. {ProductName} uses a "jaeger" route that is installed by the Jaeger operator and is already protected by OAuth.
 * {ProductName} uses a sidecar for the Envoy proxy, and Jaeger also uses a sidecar, for the Jaeger agent.

modules/ossm-kiali-architecture.adoc

@@ -17,7 +17,7 @@ In addition, Kiali depends on external services and components provided by the c
 
 * *Red Hat Service Mesh* (Istio) - Istio is a Kiali requirement. Istio is the component that provides and controls the service mesh. Although Kiali and Istio can be installed separately, Kiali depends on Istio and will not work if it is not present. Kiali needs to retrieve Istio data and configurations, which are exposed through Prometheus and the cluster API.
 
-* *Prometheus* - A dedicated Prometheus instance is included as part of the {ProductName} installation. When Istio telemetry is enabled, metrics data is stored in Prometheus. Kiali uses this Prometheus data to determine the mesh topology, display metrics, calculate health, show possible problems, and so on. Kiali communicates directly with Prometheus and assumes the data schema used by Istio Telemetery. Prometheus is an Istio dependency and a hard dependency for Kiali, and many of Kiali’s features will not work without Prometheus.
+* *Prometheus* - A dedicated Prometheus instance is included as part of the {ProductName} installation. When Istio telemetry is enabled, metrics data is stored in Prometheus. Kiali uses this Prometheus data to determine the mesh topology, display metrics, calculate health, show possible problems, and so on. Kiali communicates directly with Prometheus and assumes the data schema used by Istio Telemetry. Prometheus is an Istio dependency and a hard dependency for Kiali, and many of Kiali’s features will not work without Prometheus.
 
 * *Cluster API* - Kiali uses the API of the {product-title} (cluster API) in order to fetch and resolve service mesh configurations. Kiali queries the cluster API to retrieve, for example, definitions for namespaces, services, deployments, pods, and other entities. Kiali also makes queries to resolve relationships between the different cluster entities. The cluster API is also queried to retrieve Istio configurations like virtual services, destination rules, route rules, gateways, quotas, and so on.
 

modules/ossm-routing.adoc

@@ -218,7 +218,7 @@ A service entry adds an entry to the service registry that {ProductName} maintai
 * Define retry, timeout, and fault injection policies for external destinations.
 * Run a mesh service in a Virtual Machine (VM) by adding VMs to your mesh.
 * Logically add services from a different cluster to the mesh to configure a multicluster {ProductName} mesh on Kubernetes.
-* You don’t need to add a service entry for every external service that you want your mesh services to use. By default, {ProductName} configures the Envoy proxies to passthrough requests to unknown services. However, you can’t use {ProductName} features to control the traffic to destinations that aren’t registered in the mesh.
+* You don’t need to add a service entry for every external service that you want your mesh services to use. By default, {ProductName} configures the Envoy proxies to pass requests through to unknown services. However, you can’t use {ProductName} features to control the traffic to destinations that aren’t registered in the mesh.
 
 .Service entry examples
 The following example mesh-external service entry adds the `ext-resource` external dependency to the {ProductName} service registry:

modules/ossm-security-cert-manage.adoc

@@ -18,7 +18,7 @@ By default, {ProductName} generates self-signed root certificate and key, and us
 
 To use an existing signing (CA) certificate and key, you must create a chain of trust file that includes the CA certificate, key, and root certificate. You must use the following exact file names for each of the corresponding certificates. The CA certificate is called `ca-cert.pem`, the key is `ca-key.pem`, and the root certificate, which signs `ca-cert.pem`, is called `root-cert.pem`. If your workload uses intermediate certificates, you must specify them in a `cert-chain.pem` file.
 
-Add the certificates to {ProductShortName} by following these steps. Save the example certificates from the link:https://github.com/maistra/istio/tree/maistra-2.0/samples/certs[Maistra repo] locally and replace `<path>` with the path to your certificates.
+Add the certificates to {ProductShortName} by following these steps. Save the example certificates from the link:https://github.com/maistra/istio/tree/maistra-2.0/samples/certs[Maistra repository] locally and replace `<path>` with the path to your certificates.
 
 . Create a secret `cacert` that includes the input files `ca-cert.pem`, `ca-key.pem`, `root-cert.pem` and `cert-chain.pem`.
 +

modules/ossm-tutorial-jaeger-generating-traces.adoc

@@ -28,7 +28,7 @@ This tutorial uses {ProductShortName} and the Bookinfo tutorial to demonstrate h
 * Bookinfo example application installed.
 
 .Procedure
-. After you have deployed the Bookinfo application you will need to generate calls to the Bookinfo application so that you have some trace data to analyze. Access http://<GATEWAY_URL>/productpage and refresh the page a few times to generate some trace data.
+. After you have deployed the Bookinfo application you will need to generate calls to the Bookinfo application so that you have some trace data to analyze. Access `http://<GATEWAY_URL>/productpage` and refresh the page a few times to generate some trace data.
 . The installation process creates a route to access the Jaeger console.
 .. In the {product-title} console, navigate to *Networking* -> *Routes* and search for the Jaeger route, which is the URL listed under *Location*.
 .. Use the CLI to query for details of the route:

modules/ossm-vs-istio.adoc

@@ -11,7 +11,7 @@ An installation of {ProductName} differs from an installation of Istio in multip
 [id="ossm-cli-tool_{context}"]
 == Command line tool
 
-The command line tool for {ProductName} is oc.  {ProductName} does not support istioctl.
+The command line tool for {ProductName} is `oc`.  {ProductName} does not support `istioctl`.
 
 
 [id="ossm-installation-upgrade_{context}"]