openshift · JStickler · Apr 1, 2022 · Apr 1, 2022
diff --git a/_attributes/common-attributes.adoc b/_attributes/common-attributes.adoc
@@ -94,4 +94,3 @@ endif::[]
 :MaistraVersion: 2.1
 //Service Mesh v1
 :SMProductVersion1x: 1.1.17
-:MaistraVersionv1: 1.1
diff --git a/_attributes/ossm-document-attributes-1x.adoc b/_attributes/ossm-document-attributes-1x.adoc
diff --git a/_attributes/ossm-document-attributes.adoc b/_attributes/ossm-document-attributes.adoc
diff --git a/machine_management/creating-infrastructure-machinesets.adoc b/machine_management/creating-infrastructure-machinesets.adoc
@@ -2,7 +2,6 @@
 [id="creating-infrastructure-machinesets"]
 = Creating infrastructure machine sets
 include::_attributes/common-attributes.adoc[]
-include::_attributes/ossm-document-attributes.adoc[]
 :context: creating-infrastructure-machinesets
 
 toc::[]

diff --git a/modules/distr-tracing-accessing-jaeger-console.adoc b/modules/distr-tracing-accessing-jaeger-console.adoc
@@ -37,7 +37,7 @@ The *Location* column displays the linked address for each route.
 
 .Procedure from the CLI
 
-. Log in to the {product-title} CLI as a user with the `cluster-admin` role. If you use Red Hat OpenShift Dedicated, you must have an account with the `dedicated-admin` role.
+. Log in to the {product-title} CLI as a user with the `cluster-admin` role. If you use {product-dedicated}, you must have an account with the `dedicated-admin` role.
 +
 [source,terminal]
 ----

diff --git a/modules/distr-tracing-change-operator-20.adoc b/modules/distr-tracing-change-operator-20.adoc
@@ -19,4 +19,4 @@ As part of the update to version 2.0, you must update your OpenShift Elasticsear
 * The {product-title} version is 4.6 or later.
 * You have updated the OpenShift Elasticsearch Operator.
 * You have backed up the Jaeger custom resource file.
-* An account with the `cluster-admin` role. If you use Red Hat OpenShift Dedicated, you must have an account with the `dedicated-admin` role.
+* An account with the `cluster-admin` role. If you use {product-dedicated}, you must have an account with the `dedicated-admin` role.
diff --git a/modules/ossm-about-collecting-ossm-data.adoc b/modules/ossm-about-collecting-ossm-data.adoc
@@ -8,7 +8,7 @@
 [id="ossm-about-collecting-ossm-data_{context}"]
 = About collecting service mesh data
 
-You can use the `oc adm must-gather` CLI command to collect information about your cluster, including features and objects associated with {ProductName}.
+You can use the `oc adm must-gather` CLI command to collect information about your cluster, including features and objects associated with {SMProductName}.
 
 .Prerequisites
 
@@ -18,14 +18,14 @@ You can use the `oc adm must-gather` CLI command to collect information about yo
 
 .Precedure
 
-. To collect {ProductName} data with `must-gather`, you must specify the {ProductName} image.
+. To collect {SMProductName} data with `must-gather`, you must specify the {SMProductName} image.
 +
 [source,terminal]
 ----
 $ oc adm must-gather --image=registry.redhat.io/openshift-service-mesh/istio-must-gather-rhel8
 ----
 +
-. To collect {ProductName} data for a specific control plane namespace with `must-gather`, you must specify the {ProductName} image and namespace. In this example, replace  `<namespace>` with your control plane namespace, such as `istio-system`.
+. To collect {SMProductName} data for a specific control plane namespace with `must-gather`, you must specify the {SMProductName} image and namespace. In this example, replace  `<namespace>` with your control plane namespace, such as `istio-system`.
 +
 [source,terminal]
 ----

diff --git a/modules/ossm-architecture-1x.adoc b/modules/ossm-architecture-1x.adoc
@@ -3,9 +3,9 @@
 // -service_mesh/v1x/ossm-architecture.adoc
 
 [id="ossm-architecture-1x_{context}"]
-= {ProductName} Architecture
+= {SMProductName} Architecture
 
-{ProductName} is logically split into a data plane and a control plane:
+{SMProductName} is logically split into a data plane and a control plane:
 
 The *data plane* is a set of intelligent proxies deployed as sidecars. These proxies intercept and control all inbound and outbound network communication between microservices in the service mesh. Sidecar proxies also communicate with Mixer, the general-purpose policy and telemetry hub.
 
@@ -18,4 +18,4 @@ The *control plane* manages and configures proxies to route traffic, and configu
 * *Citadel* issues and rotates certificates. Citadel provides strong service-to-service and end-user authentication with built-in identity and credential management. You can use Citadel to upgrade unencrypted traffic in the service mesh. Operators can enforce policies based on service identity rather than on network controls using Citadel.
 * *Galley* ingests the service mesh configuration, then validates, processes, and distributes the configuration. Galley protects the other service mesh components from obtaining user configuration details from {product-title}.
 
-{ProductName} also uses the *istio-operator* to manage the installation of the control plane. An _Operator_ is a piece of software that enables you to implement and automate common activities in your {product-title} cluster. It acts as a controller, allowing you to set or change the desired state of objects in your cluster.
+{SMProductName} also uses the *istio-operator* to manage the installation of the control plane. An _Operator_ is a piece of software that enables you to implement and automate common activities in your {product-title} cluster. It acts as a controller, allowing you to set or change the desired state of objects in your cluster.
diff --git a/modules/ossm-architecture.adoc b/modules/ossm-architecture.adoc
@@ -9,7 +9,7 @@ Service mesh technology operates at the network communication level. That is, se
 
 image::ossm-architecture.png[Service Mesh architecture image]
 
-At a high level, {ProductName} consists of a data plane and a control plane
+At a high level, {SMProductName} consists of a data plane and a control plane
 
 The *data plane* is a set of intelligent proxies, running alongside application containers in a pod, that intercept and control all inbound and outbound network communication between microservices in the service mesh.
 The data plane is implemented in such a way that it intercepts all inbound (ingress) and outbound (egress) network traffic. The Istio data plane is composed of Envoy containers running along side application containers in a pod. The Envoy container acts as a proxy, controlling all network communication into and out of the pod.
@@ -32,20 +32,20 @@ The *control plane* manages and configures the proxies that make up the data pla
 
 ** Istiod is responsible for injecting sidecar proxy containers into workloads deployed to an OpenShift cluster.
 
-{ProductName} uses the *istio-operator* to manage the installation of the control plane. An _Operator_ is a piece of software that enables you to implement and automate common activities in your OpenShift cluster. It acts as a controller, allowing you to set or change the desired state of objects in your cluster, in this case, a {ProductName} installation.
+{SMProductName} uses the *istio-operator* to manage the installation of the control plane. An _Operator_ is a piece of software that enables you to implement and automate common activities in your OpenShift cluster. It acts as a controller, allowing you to set or change the desired state of objects in your cluster, in this case, a {SMProductName} installation.
 
-{ProductName} also bundles the following Istio add-ons as part of the product:
+{SMProductName} also bundles the following Istio add-ons as part of the product:
 
-* *Kiali* - Kiali is the management console for {ProductName}. It provides dashboards, observability, and robust configuration and validation capabilities. It shows the structure of your service mesh by inferring traffic topology and displays the health of your mesh. Kiali provides detailed metrics, powerful validation, access to Grafana, and strong integration with the {JaegerShortName}.
+* *Kiali* - Kiali is the management console for {SMProductName}. It provides dashboards, observability, and robust configuration and validation capabilities. It shows the structure of your service mesh by inferring traffic topology and displays the health of your mesh. Kiali provides detailed metrics, powerful validation, access to Grafana, and strong integration with the {JaegerShortName}.
 
-* *Prometheus* - {ProductName} uses Prometheus to store telemetry information from services. Kiali depends on Prometheus to obtain metrics, health status, and mesh topology.
+* *Prometheus* - {SMProductName} uses Prometheus to store telemetry information from services. Kiali depends on Prometheus to obtain metrics, health status, and mesh topology.
 
-* *Jaeger* - {ProductName} supports the {JaegerShortName}. Jaeger is an open source traceability server that centralizes and displays traces associated with a single request between multiple services. Using the {JaegerShortName} you can monitor and troubleshoot your microservices-based distributed systems.
+* *Jaeger* - {SMProductName} supports the {JaegerShortName}. Jaeger is an open source traceability server that centralizes and displays traces associated with a single request between multiple services. Using the {JaegerShortName} you can monitor and troubleshoot your microservices-based distributed systems.
 
 * *Elasticsearch* - Elasticsearch is an open source, distributed, JSON-based search and analytics engine. The {JaegerShortName} uses Elasticsearch for persistent storage.
 
 * *Grafana* - Grafana provides mesh administrators with advanced query and metrics analysis and dashboards for Istio data. Optionally, Grafana can be used to analyze service mesh metrics.
 
-The following Istio integrations are supported with {ProductName}:
+The following Istio integrations are supported with {SMProductName}:
 
 * *3scale* - Istio provides an optional integration with Red Hat 3scale API Management solutions. For versions prior to 2.1, this integration was achieved via the 3scale Istio adapter. For version 2.1 and later, the 3scale integration is achieved via a WebAssembly module.
diff --git a/modules/ossm-auto-route-1x.adoc b/modules/ossm-auto-route-1x.adoc
@@ -6,11 +6,11 @@ This TASK module included in the following assemblies:
 [id="ossm-auto-route-1x_{context}"]
 = Automatic route creation
 
-OpenShift routes for Istio Gateways are automatically managed in {ProductName}. Every time an Istio Gateway is created, updated or deleted inside the service mesh, an OpenShift route is created, updated or deleted.
+OpenShift routes for Istio Gateways are automatically managed in {SMProductName}. Every time an Istio Gateway is created, updated or deleted inside the service mesh, an OpenShift route is created, updated or deleted.
 
 [id="ossm-auto-route-enable_{context}"]
 == Enabling Automatic Route Creation
-A {ProductName} control plane component called Istio OpenShift Routing (IOR) synchronizes the gateway route. Enable IOR as part of the control plane deployment.
+A {SMProductName} control plane component called Istio OpenShift Routing (IOR) synchronizes the gateway route. Enable IOR as part of the control plane deployment.
 
 If the Gateway contains a TLS section, the OpenShift Route will be configured to support TLS.
 
@@ -36,7 +36,7 @@ spec:
 [id="ossm-auto-route-subdomains_{context}"]
 == Subdomains
 
-{ProductName} creates the route with the subdomain, but {product-title} must be configured to enable it. Subdomains, for example `*.domain.com`, are supported but not by default. Configure an {product-title} wildcard policy before configuring a wildcard host Gateway. For more information, see the "Links" section.
+{SMProductName} creates the route with the subdomain, but {product-title} must be configured to enable it. Subdomains, for example `*.domain.com`, are supported but not by default. Configure an {product-title} wildcard policy before configuring a wildcard host Gateway. For more information, see the "Links" section.
 
 If the following gateway is created:
 
@@ -74,4 +74,4 @@ gateway1-lvlfn bookinfo.example.com        istio-ingressgateway   <all>
 gateway1-scqhv www.bookinfo.com            istio-ingressgateway   <all>               None
 ----
 
-If the gateway is deleted, {ProductName} deletes the routes. However, routes created manually are never modified by {ProductName}.
+If the gateway is deleted, {SMProductName} deletes the routes. However, routes created manually are never modified by {SMProductName}.
diff --git a/modules/ossm-auto-route-annotations.adoc b/modules/ossm-auto-route-annotations.adoc
@@ -3,8 +3,8 @@
 //
 
 [id="ossm-auto-route-annotations_{context}"]
-= {ProductName} route annotations
+= {SMProductName} route annotations
 
-Sometimes specific annotations are needed in an OpenShift Route. For example, some advanced features in OpenShift Routes are managed via xref:../../networking/routes/route-configuration.adoc[special annotations]. For this and other use cases, {ProductName} will copy all annotations present in the Istio Gateway resource (with the exception of those starting with `kubectl.kubernetes.io`) into the managed OpenShift Route resource.
+Sometimes specific annotations are needed in an OpenShift Route. For example, some advanced features in OpenShift Routes are managed via xref:../../networking/routes/route-configuration.adoc[special annotations]. For this and other use cases, {SMProductName} will copy all annotations present in the Istio Gateway resource (with the exception of those starting with `kubectl.kubernetes.io`) into the managed OpenShift Route resource.
 
-If you need specific annotations in the OpenShift Routes created by {ProductShortName}, create them in the Istio Gateway resource and they will be copied into the OpenShift Route resources managed by the {ProductShortName}.
+If you need specific annotations in the OpenShift Routes created by {SMProductShortName}, create them in the Istio Gateway resource and they will be copied into the OpenShift Route resources managed by the {SMProductShortName}.
diff --git a/modules/ossm-auto-route.adoc b/modules/ossm-auto-route.adoc
@@ -41,4 +41,4 @@ gateway1-lvlfn bookinfo.example.com        istio-ingressgateway   <all>
 gateway1-scqhv www.bookinfo.com            istio-ingressgateway   <all>               None
 ----
 
-If the gateway is deleted, {ProductName} deletes the routes. However, routes created manually are never modified by {ProductName}.
+If the gateway is deleted, {SMProductName} deletes the routes. However, routes created manually are never modified by {SMProductName}.
diff --git a/modules/ossm-config-disable-networkpolicy.adoc b/modules/ossm-config-disable-networkpolicy.adoc
@@ -10,12 +10,12 @@ If you want to disable the automatic creation and management of `NetworkPolicy`
 
 [NOTE]
 ====
-When you disable `spec.security.manageNetworkPolicy` {ProductName} will not create *any* `NetworkPolicy` objects.  The system administrator is responsible for managing the network and fixing any issues this might cause.
+When you disable `spec.security.manageNetworkPolicy` {SMProductName} will not create *any* `NetworkPolicy` objects.  The system administrator is responsible for managing the network and fixing any issues this might cause.
 ====
 
 .Prerequisites
 
-* {ProductName} Operator version 2.1.1 or higher installed.
+* {SMProductName} Operator version 2.1.1 or higher installed.
 * `ServiceMeshControlPlane` resource updated to version 2.1 or higher.
 
 .Procedure
@@ -24,7 +24,7 @@ When you disable `spec.security.manageNetworkPolicy` {ProductName} will not crea
 
 . Select the project where you installed the control plane, for example `istio-system`, from the *Project* menu.
 
-. Click the {ProductName} Operator. In the *Istio Service Mesh Control Plane* column, click the name of your `ServiceMeshControlPlane`, for example `basic-install`.
+. Click the {SMProductName} Operator. In the *Istio Service Mesh Control Plane* column, click the name of your `ServiceMeshControlPlane`, for example `basic-install`.
 
 . On the *Create ServiceMeshControlPlane Details* page, click `YAML` to modify your configuration.
 

diff --git a/modules/ossm-config-external-jaeger.adoc b/modules/ossm-config-external-jaeger.adoc
@@ -19,7 +19,7 @@ If you already have an existing {JaegerName} instance in {product-title}, you ca
 
 . Click the *Project* menu and select the project where you installed the control plane, for example *istio-system*.
 
-. Click the {ProductName} Operator. In the *Istio Service Mesh Control Plane* column, click the name of your `ServiceMeshControlPlane` resource, for example `basic`.
+. Click the {SMProductName} Operator. In the *Istio Service Mesh Control Plane* column, click the name of your `ServiceMeshControlPlane` resource, for example `basic`.
 
 . Add the name of your {JaegerShortName} instance to the `ServiceMeshControlPlane`.
 +

diff --git a/modules/ossm-config-network-policy.adoc b/modules/ossm-config-network-policy.adoc
@@ -8,7 +8,7 @@ This CONCEPT module included in the following assemblies:
 
 == Setting the correct network policy
 
-{ProductShortName} creates network policies in the control plane and member namespaces to allow traffic between them. Before you deploy, consider the following conditions to ensure the services in your service mesh that were previously exposed through an {product-title} route.
+{SMProductShortName} creates network policies in the control plane and member namespaces to allow traffic between them. Before you deploy, consider the following conditions to ensure the services in your service mesh that were previously exposed through an {product-title} route.
 
 * Traffic into the service mesh must always go through the ingress-gateway for Istio to work properly.
 * Deploy services external to the service mesh in separate namespaces that are not in any service mesh.