Merge pull request #68302 from mburke5678/service-mesh-fix-errors-2

mburke5678 · web-flow · commit 8312d53e6f6c · 2024-03-28T17:47:32.000-04:00
Service Mesh docs fixes during ROSA review 2
diff --git a/modules/distr-tracing-upgrading-es5-es6.adoc b/modules/distr-tracing-upgrading-es5-es6.adoc
@@ -14,7 +14,7 @@ When updating from Elasticsearch 5 to 6, you must delete your {JaegerShortName}
 +
 [source,terminal]
 ----
-$ oc get jaeger -n <istio-system>
+$ oc get jaeger -n istio-system
 ----
 +
 You will see output similar to the following:
@@ -29,21 +29,21 @@ jaeger  Running  1.24.1     production   elasticsearch   d21h
 +
 [source,terminal]
 ----
-$ oc get jaeger jaeger -oyaml -n <istio-system> > /tmp/jaeger-cr.yaml
+$ oc get jaeger jaeger -oyaml -n istio-system > /tmp/jaeger-cr.yaml
 ----
 
 . Delete the {JaegerShortName} instance by running the following command:
 +
 [source,terminal]
 ----
-$ oc delete jaeger jaeger -n <istio-system>
+$ oc delete jaeger jaeger -n istio-system
 ----
 
 . Recreate the {JaegerShortName} instance from your copy of the custom resource file by running the following command:
 +
 [source,terminal]
 ----
-$ oc create -f /tmp/jaeger-cr.yaml -n <istio-system>
+$ oc create -f /tmp/jaeger-cr.yaml -n istio-system
 ----
 
 . Delete the copy of the generated custom resource file by running the following command:
diff --git a/modules/ossm-accessing-jaeger.adoc b/modules/ossm-accessing-jaeger.adoc
@@ -23,7 +23,7 @@ search for the Jaeger route, which is the URL listed under *Location*.
 +
 [source,terminal]
 ----
-$ export JAEGER_URL=$(oc get route -n istio-system jaeger -o jsonpath='{.spec.host}')
+$ oc get route -n istio-system jaeger -o jsonpath='{.spec.host}'
 ----
 +
 . Launch a browser and navigate to ``\https://<JAEGER_URL>``, where `<JAEGER_URL>` is the route that you discovered in the previous step.
diff --git a/modules/ossm-cert-manager-installation.adoc b/modules/ossm-cert-manager-installation.adoc
@@ -12,15 +12,7 @@ You can install the `cert-manager` tool to manage the lifecycle of TLS certifica
 
 . Create the root cluster issuer:
 +
-[source,terminal]
-----
-$ oc apply -f cluster-issuer.yaml
-----
-+
-[source,terminal]
-----
-$ oc apply -n istio-system -f istio-ca.yaml
-----
+.. Create the `cluster-issuer` object as in the following example:
 +
 .Example `cluster-issuer.yaml`
 [source, yaml]
@@ -60,6 +52,20 @@ spec:
     secretName: root-ca
 ----
 +
+====
+[NOTE]
+The namespace of the `selfsigned-root-issuer` issuer and `root-ca` certificate is `cert-manager` because `root-ca` is a cluster issuer, so the cert-manager looks for a referenced secret in its own namespace. The namespace is called `cert-manager` in the case of the {cert-manager-operator}.
+====
+
+.. Create the object by using the following command:
++
+[source,terminal]
+----
+$ oc apply -f cluster-issuer.yaml
+----
+
+.. Create the `istio-ca` object as in the following example:
++
 .Example `istio-ca.yaml`
 [source, yaml]
 ----
@@ -90,11 +96,13 @@ spec:
   ca:
     secretName: istio-ca
 ----
+
+.. Use the following command to create the object:
 +
-====
-[NOTE]
-The namespace of the `selfsigned-root-issuer` issuer and `root-ca` certificate is `cert-manager` because `root-ca` is a cluster issuer, so the cert-manager looks for a referenced secret in its own namespace. Its own namespace is `cert-manager` in the case of the {cert-manager-operator}.
-====
+[source,terminal]
+----
+$ oc apply -n istio-system -f istio-ca.yaml
+----
 
 . Install `istio-csr`:
 +
diff --git a/modules/ossm-federation-config-smcp.adoc b/modules/ossm-federation-config-smcp.adoc
@@ -321,6 +321,13 @@ In the following example, the administrator is configuring the SMCP for federati
 .Sample SMCP for NodePort
 [source,yaml]
 ----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: green-mesh
+  namespace: green-mesh-system
+spec:
+# ...
   gateways:
      additionalIngress:
       ingress-green-mesh:
diff --git a/modules/ossm-federation-create-export.adoc b/modules/ossm-federation-create-export.adoc
@@ -103,22 +103,11 @@ $ oc create -n red-mesh-system -f export-to-green-mesh.yaml
 ----
 +
 . Create additional `ExportedServiceSets` as needed for each mesh peer in your federated mesh.
+
+.Verification
+
 //TODO - Add sample output after the validation
-. To validate the services you've exported from `red-mesh` to share with `green-mesh`, run the following command:
-+
-[source,terminal]
-----
-$ oc get exportedserviceset <PeerMeshExportedTo> -o yaml
-----
-+
-For example:
-+
-[source,terminal]
-----
-$ oc get exportedserviceset green-mesh -o yaml
-----
-+
-. Run the following command to validate the services the red-mesh exports to share with green-mesh:
+* Run the following command to validate the services the red-mesh exports to share with green-mesh:
 +
 [source,terminal]
 ----
diff --git a/modules/ossm-federation-create-import.adoc b/modules/ossm-federation-create-import.adoc
@@ -41,7 +41,7 @@ Follow this procedure to create an `ImportedServiceSet` with the web console. Th
 ////
 
 
-.Procedure from the CLI
+.Procedure
 
 Follow this procedure to create an `ImportedServiceSet` from the command line.
 
@@ -96,29 +96,19 @@ $ oc create -n green-mesh-system -f import-from-red-mesh.yaml
 ----
 +
 . Create additional `ImportedServiceSet` resources as needed for each mesh peer in your federated mesh.
+
+.Verification
+
 //TODO - Add sample output after the validation
-. To validate the services you've imported into `green-mesh`, run the following command:
-+
-[source,terminal]
-----
-$ oc get importedserviceset <PeerMeshImportedInto> -o yaml
-----
-+
-For example:
-+
-[source,terminal]
-----
-$ oc get importedserviceset green-mesh -o yaml
-----
-+
-. Run the following command to validate the services imported into a mesh.
+
+* Run the following command to verify that the services were imported into `green-mesh`:
 +
 [source,terminal]
 ----
 $ oc get importedserviceset <PeerMeshImportedInto> -o yaml
 ----
 +
-.Example validating that the services exported from the red mesh have been imported into the green mesh using the status section of the `importedserviceset/red-mesh' object in the 'green-mesh-system` namespace:
+.Example verifying that the services exported from the red mesh have been imported into the green mesh using the status section of the `importedserviceset/red-mesh' object in the 'green-mesh-system` namespace:
 +
 [source,terminal]
 ----
diff --git a/modules/ossm-jaeger-accessing-console.adoc b/modules/ossm-jaeger-accessing-console.adoc
@@ -50,7 +50,7 @@ $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
 +
 [source,terminal]
 ----
-$ export JAEGER_URL=$(oc get route -n istio-system jaeger -o jsonpath='{.spec.host}')
+$ oc get route -n istio-system jaeger -o jsonpath='{.spec.host}'
 ----
 +
 . Launch a browser and navigate to ``\https://<JAEGER_URL>``, where `<JAEGER_URL>` is the route that you discovered in the previous step.
diff --git a/modules/ossm-mixer-policy-1x.adoc b/modules/ossm-mixer-policy-1x.adoc
@@ -13,7 +13,7 @@ In previous versions of {SMProductName}, Mixer's policy enforcement was enabled
 
 [NOTE]
 ====
-The examples use `<istio-system>` as the control plane namespace. Replace this value with the namespace where you deployed the Service Mesh Control Plane (SMCP).
+The examples use `istio-system` as the control plane namespace. Replace this value with the namespace where you deployed the Service Mesh Control Plane (SMCP).
 ====
 
 .Procedure
@@ -24,14 +24,14 @@ The examples use `<istio-system>` as the control plane namespace. Replace this v
 +
 [source,terminal]
 ----
-$ oc get cm -n <istio-system> istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks
+$ oc get cm -n istio-system istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks
 ----
 
 . If `disablePolicyChecks: true`, edit the {SMProductShortName} ConfigMap:
 +
 [source,terminal]
 ----
-$ oc edit cm -n <istio-system> istio
+$ oc edit cm -n istio-system istio
 ----
 
 . Locate `disablePolicyChecks: true` within the ConfigMap and change the value to `false`.
diff --git a/modules/ossm-mixer-policy.adoc b/modules/ossm-mixer-policy.adoc
@@ -13,7 +13,7 @@ In previous versions of {SMProductName}, Mixer's policy enforcement was enabled
 
 [NOTE]
 ====
-The examples use `<istio-system>` as the {SMProductShortName} control plane namespace. Replace this value with the namespace where you deployed the Service Mesh Control Plane (SMCP).
+The examples use `istio-system` as the {SMProductShortName} control plane namespace. Replace this value with the namespace where you deployed the Service Mesh Control Plane (SMCP).
 ====
 
 .Procedure
@@ -24,14 +24,14 @@ The examples use `<istio-system>` as the {SMProductShortName} control plane name
 +
 [source,terminal]
 ----
-$ oc get cm -n <istio-system> istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks
+$ oc get cm -n istio-system istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks
 ----
 
 . If `disablePolicyChecks: true`, edit the {SMProductShortName} ConfigMap:
 +
 [source,terminal]
 ----
-$ oc edit cm -n <istio-system> istio
+$ oc edit cm -n istio-system istio
 ----
 
 . Locate `disablePolicyChecks: true` within the ConfigMap and change the value to `false`.
diff --git a/modules/ossm-recommended-resources.adoc b/modules/ossm-recommended-resources.adoc
@@ -76,4 +76,6 @@ spec:
 +
 .. Click *Save*.
 
-. Click *Reload* to verify the `ServiceMeshControlPlane` resource was configured correctly.
+.Verification
+
+* Click *Reload* to verify that the `ServiceMeshControlPlane` resource was configured correctly.
diff --git a/modules/ossm-rn-fixed-issues.adoc b/modules/ossm-rn-fixed-issues.adoc
@@ -101,10 +101,14 @@ In the following example, the `oc label` command removes the `ignore-namespace`
 +
 [source,terminal]
 ----
-$ oc label namespace <istio_system> maistra.io/ignore-namespace-
+$ oc label namespace istio-system maistra.io/ignore-namespace-
 ----
 +
-In the example above, <istio_system> represents the name of the `ServiceMeshControlPlane` namespace.
+where:
++
+--
+istio_system :: Specified the name of the `ServiceMeshControlPlane` namespace.
+--
 
 * https://issues.redhat.com/browse/OSSM-2053[OSSM-2053] Using {SMProductName} Operator 2.2 or 2.3, during SMCP reconciliation, the SMMR controller removed the member namespaces from `SMMR.status.configuredMembers`. This caused the services in the member namespaces to become unavailable for a few moments.
 +
@@ -174,7 +178,7 @@ Now, the Operator ignores resources that does not also include the `app.kubernet
 
 * 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.
+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:
 
diff --git a/modules/ossm-routing-virtual-service.adoc b/modules/ossm-routing-virtual-service.adoc
@@ -25,7 +25,7 @@ Without virtual services, {SMProductName} distributes traffic using least reques
 . Create a YAML file using the following example to route requests to different versions of the Bookinfo sample application service depending on which user connects to the application.
 +
 .Example VirtualService.yaml
-[source,YAML]
+[source,yaml]
 ----
 apiVersion: networking.istio.io/v1alpha3
 kind: VirtualService
diff --git a/modules/ossm-security-auth-policy.adoc b/modules/ossm-security-auth-policy.adoc
@@ -46,7 +46,7 @@ spec:
   rules:
   - from:
     - source:
-      ipBlocks: ["1.2.3.4"]
+        ipBlocks: ["1.2.3.4"]
 ----
 +
 . Run the following command after you write your resource to create your resource in your namespace. The namespace must match your `metadata.namespace` field in your `AuthorizationPolicy` resource.
diff --git a/modules/ossm-smcp-prod.adoc b/modules/ossm-smcp-prod.adoc
@@ -47,7 +47,9 @@ spec:
 
 . Ensure your security certificates are production ready by installing security certificates from an external certificate authority. For more information, see the Security section.
 
-. Verify the results. Enter the following command to verify that the `ServiceMeshControlPlane` resource updated properly. In this example, `basic` is the name of the `ServiceMeshControlPlane` resource.
+.Verification
+
+. Enter the following command to verify that the `ServiceMeshControlPlane` resource updated properly. In this example, `basic` is the name of the `ServiceMeshControlPlane` resource.
 +
 [source,terminal]
 ----
diff --git a/modules/ossm-threescale-applying-external-service-entry-objects.adoc b/modules/ossm-threescale-applying-external-service-entry-objects.adoc
@@ -16,7 +16,7 @@ The custom resources (CRs) set up the service entries and destination rules for
 .. Add the `ServiceEntry` CR to a file called `service-entry-threescale-saas-backend.yml`:
 +
 .ServiceEntry CR
-[source,terminal]
+[source,yaml]
 ----
 apiVersion: networking.istio.io/v1beta1
 kind: ServiceEntry
@@ -35,7 +35,7 @@ spec:
 .. Add the `DestinationRule` CR to a file called `destination-rule-threescale-saas-backend.yml`:
 +
 .DestinationRule CR
-[source,terminal]
+[source,yaml]
 ----
 apiVersion: networking.istio.io/v1beta1
 kind: DestinationRule
diff --git a/modules/ossm-threescale-istio-adapter-verification.adoc b/modules/ossm-threescale-istio-adapter-verification.adoc
@@ -15,12 +15,12 @@ You might want to check whether the 3scale Istio adapter is working as expected.
 +
 [source,terminal]
 ----
-$ oc get pods -n <istio-system>
+$ oc get pods -n istio-system
 ----
 . Check that the _3scale-adapter_ pod has printed out information about itself booting up, such as its version:
 +
 [source,terminal]
 ----
-$ oc logs <istio-system>
+$ oc logs istio-system
 ----
 . When performing requests to the services protected by the 3scale adapter integration, always try requests that lack the right credentials and ensure they fail. Check the 3scale adapter logs to gather additional information.
diff --git a/modules/ossm-threescale-webassembly-module-api-object.adoc b/modules/ossm-threescale-webassembly-module-api-object.adoc
@@ -23,7 +23,7 @@ metadata:
 spec:
   pluginConfig:
     api: v1
-...
+# ...
 ----
 
 The `api` entry defines the rest of the values for the configuration. The only accepted value is `v1`. New settings that break compatibility with the current configuration or need more logic that modules using `v1` cannot handle, will require different values.
diff --git a/modules/ossm-threescale-webassembly-module-backend-object.adoc b/modules/ossm-threescale-webassembly-module-backend-object.adoc
@@ -15,11 +15,11 @@ metadata:
   name: <threescale_wasm_plugin_name>
 spec:
   pluginConfig:
-    ...
+# ...
     backend:
       name: backend
       upstream: <object>
-    ...
+# ...
 ----
 
 .`backend` object fields
diff --git a/modules/ossm-threescale-webassembly-module-credentials-object.adoc b/modules/ossm-threescale-webassembly-module-credentials-object.adoc
@@ -17,13 +17,13 @@ metadata:
   name: <threescale_wasm_plugin_name>
 spec:
   pluginConfig:
-    ...
+# ...
     services:
     - credentials:
         user_key: <array_of_lookup_queries>
         app_id: <array_of_lookup_queries>
         app_key: <array_of_lookup_queries>
-    ...
+# ...
 ----
 
 .`credentials` object fields
diff --git a/modules/ossm-threescale-webassembly-module-examples-for-credentials-use-cases.adoc b/modules/ossm-threescale-webassembly-module-examples-for-credentials-use-cases.adoc
diff --git a/modules/ossm-threescale-webassembly-module-lookup-queries.adoc b/modules/ossm-threescale-webassembly-module-lookup-queries.adoc
diff --git a/modules/ossm-threescale-webassembly-module-mapping-rule-object.adoc b/modules/ossm-threescale-webassembly-module-mapping-rule-object.adoc
diff --git a/modules/ossm-threescale-webassembly-module-services-object.adoc b/modules/ossm-threescale-webassembly-module-services-object.adoc
diff --git a/modules/ossm-threescale-webassembly-module-system-object.adoc b/modules/ossm-threescale-webassembly-module-system-object.adoc
diff --git a/modules/ossm-threescale-webassembly-module-upstream-object.adoc b/modules/ossm-threescale-webassembly-module-upstream-object.adoc
diff --git a/modules/ossm-troubleshooting-proxy.adoc b/modules/ossm-troubleshooting-proxy.adoc
diff --git a/modules/ossm-validating-smcp.adoc b/modules/ossm-validating-smcp.adoc

Original file line number	Diff line number	Diff line change
`@@ -23,7 +23,7 @@ search for the Jaeger route, which is the URL listed under Location.`
`23`	`23`	`+`
`24`	`24`	`[source,terminal]`
`25`	`25`	`----`
`26`		`-$ export JAEGER_URL=$(oc get route -n istio-system jaeger -o jsonpath='{.spec.host}')`
	`26`	`+$ oc get route -n istio-system jaeger -o jsonpath='{.spec.host}'`
`27`	`27`	`----`
`28`	`28`	`+`
`29`	`29`	. Launch a browser and navigate to ``\https://<JAEGER_URL>``, where `<JAEGER_URL>` is the route that you discovered in the previous step.
Original file line number	Diff line number	Diff line change
`@@ -50,7 +50,7 @@ $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443`
`50`	`50`	`+`
`51`	`51`	`[source,terminal]`
`52`	`52`	`----`
`53`		`-$ export JAEGER_URL=$(oc get route -n istio-system jaeger -o jsonpath='{.spec.host}')`
	`53`	`+$ oc get route -n istio-system jaeger -o jsonpath='{.spec.host}'`
`54`	`54`	`----`
`55`	`55`	`+`
`56`	`56`	. Launch a browser and navigate to ``\https://<JAEGER_URL>``, where `<JAEGER_URL>` is the route that you discovered in the previous step.
Original file line number	Diff line number	Diff line change
`@@ -76,4 +76,6 @@ spec:`
`76`	`76`	`+`
`77`	`77`	`.. Click Save.`
`78`	`78`
`79`		-. Click Reload to verify the `ServiceMeshControlPlane` resource was configured correctly.
	`79`	`+.Verification`
	`80`	`+`
	`81`	+* Click Reload to verify that the `ServiceMeshControlPlane` resource was configured correctly.