diff --git a/_attributes/common-attributes.adoc b/_attributes/common-attributes.adoc index 2196c8ec80b9..1443a22f679b 100644 --- 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 deleted file mode 100644 index 66714541ef16..000000000000 --- a/_attributes/ossm-document-attributes-1x.adoc +++ /dev/null @@ -1,37 +0,0 @@ -// Standard document attributes to be used in the Service Mesh documentation v1.x -// -// The following are shared by all RHOSSM documents: -:toc: -:toclevels: 4 -:toc-title: -:experimental: -// -// Product content attributes, that is, substitution variables in the files. -// -:product-title: OpenShift Container Platform -:ProductName: Red Hat OpenShift Service Mesh -:ProductShortName: Service Mesh -:ProductRelease: -:ProductVersion: 1.1.16 -:MaistraVersion: 1.1 -:DownloadURL: registry.redhat.io -:cluster-manager-first: Red Hat OpenShift Cluster Manager -:kebab: image:kebab.png[title="Options menu"] -// -// Documentation publishing attributes used in the master-docinfo.xml file -// Note that the DocInfoProductName generates the URL for the product page. -// Changing the value changes the generated URL. -// -:DocInfoProductName: OpenShift Service Mesh -:DocInfoProductNumber: 1.0 -// -// Book Names: -// Defining the book names in document attributes instead of hard-coding them in -// the master.adoc files and in link references. This makes it easy to change the -// book name if necessary. -// Using the pattern ending in 'BookName' makes it easy to grep for occurrences -// throughout the topics -// -:Install_BookName: Installing Red Hat OpenShift Service Mesh -:Using_BookName: Using Red Hat OpenShift Service Mesh -:RN_BookName: Red Hat OpenShift Service Mesh Release Notes diff --git a/_attributes/ossm-document-attributes.adoc b/_attributes/ossm-document-attributes.adoc deleted file mode 100644 index 43853f67bc4d..000000000000 --- a/_attributes/ossm-document-attributes.adoc +++ /dev/null @@ -1,47 +0,0 @@ -// Standard document attributes to be used in the Service Mesh documentation -// -// The following are shared by all RHOSSM documents: -:toc: -:toclevels: 4 -:toc-title: -:experimental: -:DownloadURL: registry.redhat.io -:cluster-manager-first: Red Hat OpenShift Cluster Manager -:kebab: image:kebab.png[title="Options menu"] - -// Service Mesh product content attributes, that is, substitution variables in the files. -:product-title: OpenShift Container Platform -:product-dedicated: Red Hat OpenShift Dedicated -:ProductName: Red Hat OpenShift Service Mesh -:ProductShortName: Service Mesh -:ProductRelease: -:ProductVersion: 2.1.1 -:MaistraVersion: 2.1 -:product-build: - -// Distributed Tracing product content attributes, for modules used in both products -:DTProductName: Red Hat OpenShift distributed tracing -:DTShortName: distributed tracing -:DTProductVersion: 2.0 -:JaegerName: Red Hat OpenShift distributed tracing platform -:JaegerShortName: distributed tracing platform -:JaegerVersion: 1.28.0 -:OTELName: Red Hat OpenShift distributed tracing data collection -:OTELShortName: distributed tracing data collection -:OTELVersion: 0.33.0 -// -// Documentation publishing attributes used in the master-docinfo.xml file -// Note that the DocInfoProductName generates the URL for the product page. -// Changing the value changes the generated URL. -// -:DocInfoProductName: OpenShift Service Mesh -:DocInfoProductNumber: 2.0 -// - -//Book Names: -//Defining the book names in document attributes instead of hard-coding them in the master.adoc files and in link references. This makes it easy to change the book name if necessary. -//Using the pattern ending in 'BookName' makes it easy to grep for occurrences throughout the topics - -:RN_BookName: Red Hat OpenShift Service Mesh Release Notes -:Install_BookName: Installing Red Hat OpenShift Service Mesh -:Using_BookName: Using Red Hat OpenShift Service Mesh diff --git a/machine_management/creating-infrastructure-machinesets.adoc b/machine_management/creating-infrastructure-machinesets.adoc index 997d33bb484d..61f4c0ff4c59 100644 --- 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 index 820186641e1b..5fc7083ed6db 100644 --- 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 index d4442a7d8c91..003c77bc8727 100644 --- 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 index 4bc366da26cb..ee1a7bdce8f6 100644 --- 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 `` 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 `` 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 index 6c4fc5b621cb..eab24ab618a7 100644 --- 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 index 07ad72742ea5..28e0f90ca611 100644 --- 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 index 628a6101be3c..b306328061d2 100644 --- 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 gateway1-scqhv www.bookinfo.com istio-ingressgateway 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 index 6aee907df3a2..fe3578feddc9 100644 --- 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 index 90b845c5571f..3394cb52398b 100644 --- a/modules/ossm-auto-route.adoc +++ b/modules/ossm-auto-route.adoc @@ -41,4 +41,4 @@ gateway1-lvlfn bookinfo.example.com istio-ingressgateway gateway1-scqhv www.bookinfo.com istio-ingressgateway 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 index 18913d690d5c..526648234d5d 100644 --- 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 index 8222d239c96d..b3e6fa555283 100644 --- 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 index a13523720e86..ac4d74d31505 100644 --- 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. diff --git a/modules/ossm-config-sampling.adoc b/modules/ossm-config-sampling.adoc index 6ba876d3a4f1..792b00a93f45 100644 --- a/modules/ossm-config-sampling.adoc +++ b/modules/ossm-config-sampling.adoc @@ -8,7 +8,7 @@ This module is included in the following assemblies: A trace is an execution path between services in the service mesh. A trace is comprised of one or more spans. A span is a logical unit of work that has a name, start time, and duration. The sampling rate determines how often a trace is persisted. -The Envoy proxy sampling rate is set to sample 100% of traces in your service mesh by default. A high sampling rate consumes cluster resources and performance but is useful when debugging issues. Before you deploy {ProductName} in production, set the value to a smaller proportion of traces. For example, set `spec.tracing.sampling` to `100` to sample 1% of traces. +The Envoy proxy sampling rate is set to sample 100% of traces in your service mesh by default. A high sampling rate consumes cluster resources and performance but is useful when debugging issues. Before you deploy {SMProductName} in production, set the value to a smaller proportion of traces. For example, set `spec.tracing.sampling` to `100` to sample 1% of traces. Configure the Envoy proxy sampling rate as a scaled integer representing 0.01% increments. @@ -30,7 +30,7 @@ The Jaeger remote sampling rate applies to applications that are external to the . 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`. . To adjust the sampling rate, set a different value for `spec.tracing.sampling`. + diff --git a/modules/ossm-config-security.adoc b/modules/ossm-config-security.adoc index a81cf7556549..5d59de0cc240 100644 --- a/modules/ossm-config-security.adoc +++ b/modules/ossm-config-security.adoc @@ -6,7 +6,7 @@ [id="ossm-config-security_{context}"] = Security -If your service mesh application is constructed with a complex array of microservices, you can use {ProductName} to customize the security of the communication between those services. The infrastructure of {product-title} along with the traffic management features of {ProductShortName} help you manage the complexity of your applications and secure microservices. +If your service mesh application is constructed with a complex array of microservices, you can use {SMProductName} to customize the security of the communication between those services. The infrastructure of {product-title} along with the traffic management features of {SMProductShortName} help you manage the complexity of your applications and secure microservices. .Before you begin diff --git a/modules/ossm-config-sidecar-out-mtls.adoc b/modules/ossm-config-sidecar-out-mtls.adoc index 630fe7954661..deab64b0a359 100644 --- a/modules/ossm-config-sidecar-out-mtls.adoc +++ b/modules/ossm-config-sidecar-out-mtls.adoc @@ -6,7 +6,7 @@ [id="ossm-security-mtls-sidecars-outgoing_{context}"] == Configuring sidecars for outgoing connections -Create a destination rule to configure {ProductShortName} to use mTLS when sending requests to other services in the mesh. +Create a destination rule to configure {SMProductShortName} to use mTLS when sending requests to other services in the mesh. .Procedure diff --git a/modules/ossm-config-web-console.adoc b/modules/ossm-config-web-console.adoc index 66a31af7fd6c..ba5a862377c9 100644 --- a/modules/ossm-config-web-console.adoc +++ b/modules/ossm-config-web-console.adoc @@ -14,7 +14,7 @@ You can configure the `ServiceMeshControlPlane` by using the {product-title} web . 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`. . On the *Details* page, click the toggle. diff --git a/modules/ossm-configuring-jaeger-v1x.adoc b/modules/ossm-configuring-jaeger-v1x.adoc index e058bcd5c8c2..69f7a887fb0b 100644 --- a/modules/ossm-configuring-jaeger-v1x.adoc +++ b/modules/ossm-configuring-jaeger-v1x.adoc @@ -6,7 +6,7 @@ [id="ossm-configuring-jaeger_{context}"] = Configuring Jaeger -When the {ProductShortName} Operator creates the `ServiceMeshControlPlane` resource it can also create the resources for distributed tracing. {ProductShortName} uses Jaeger for distributed tracing. +When the {SMProductShortName} Operator creates the `ServiceMeshControlPlane` resource it can also create the resources for distributed tracing. {SMProductShortName} uses Jaeger for distributed tracing. You can specify your Jaeger configuration in either of two ways: @@ -52,7 +52,7 @@ spec: [NOTE] ==== -The default template in the `ServiceMeshControlPlane` resource is the `all-in-one` deployment strategy which uses in-memory storage. For production, the only supported storage option is Elasticsearch, therefore you must configure the `ServiceMeshControlPlane` to request the `production-elasticsearch` template when you deploy {ProductShortName} within a production environment. +The default template in the `ServiceMeshControlPlane` resource is the `all-in-one` deployment strategy which uses in-memory storage. For production, the only supported storage option is Elasticsearch, therefore you must configure the `ServiceMeshControlPlane` to request the `production-elasticsearch` template when you deploy {SMProductShortName} within a production environment. ==== @@ -61,7 +61,7 @@ The default template in the `ServiceMeshControlPlane` resource is the `all-in-on The default Jaeger deployment strategy uses the `all-in-one` template so that the installation can be completed using minimal resources. However, because the `all-in-one` template uses in-memory storage, it is only recommended for development, demo, or testing purposes and should NOT be used for production environments. -If you are deploying {ProductShortName} and Jaeger in a production environment you must change the template to the `production-elasticsearch` template, which uses Elasticsearch for Jaeger's storage needs. +If you are deploying {SMProductShortName} and Jaeger in a production environment you must change the template to the `production-elasticsearch` template, which uses Elasticsearch for Jaeger's storage needs. Elasticsearch is a memory intensive application. The initial set of nodes specified in the default {product-title} installation may not be large enough to support the Elasticsearch cluster. You should modify the default Elasticsearch configuration to match your use case and the resources you have requested for your {product-title} installation. You can adjust both the CPU and memory limits for each component by modifying the resources block with valid CPU and memory values. Additional nodes must be added to the cluster if you want to run with the recommended amount (or more) of memory. Ensure that you do not exceed the resources requested for your {product-title} installation. @@ -98,7 +98,7 @@ spec: |tracing: enabled: -|This parameter enables/disables tracing in {ProductShortName}. Jaeger is installed by default. +|This parameter enables/disables tracing in {SMProductShortName}. Jaeger is installed by default. |`true`/`false` |`true` | @@ -168,7 +168,7 @@ Minimum deployment = 16Gi* . Navigate to *Operators* -> *Installed Operators*. -. Click the {ProductName} Operator. +. Click the {SMProductName} Operator. . Click the *Istio Service Mesh Control Plane* tab. diff --git a/modules/ossm-configuring-kiali.adoc b/modules/ossm-configuring-kiali.adoc index e406742be83b..0b7cd4b9ac26 100644 --- a/modules/ossm-configuring-kiali.adoc +++ b/modules/ossm-configuring-kiali.adoc @@ -6,7 +6,7 @@ [id="configuring-kiali_{context}"] = Configuring Kiali -When the {ProductShortName} Operator creates the `ServiceMeshControlPlane` it also processes the Kiali resource. The Kiali Operator then uses this object when creating Kiali instances. +When the {SMProductShortName} Operator creates the `ServiceMeshControlPlane` it also processes the Kiali resource. The Kiali Operator then uses this object when creating Kiali instances. The default Kiali parameters specified in the `ServiceMeshControlPlane` are as follows: @@ -37,7 +37,7 @@ spec: |dashboard viewOnlyMode -|This parameter enables/disables view-only mode for the Kiali console. When view-only mode is enabled, users cannot use the console to make changes to the {ProductShortname}. +|This parameter enables/disables view-only mode for the Kiali console. When view-only mode is enabled, users cannot use the console to make changes to the {SMProductShortName}. |`true`/`false` |`false` @@ -51,7 +51,7 @@ spec: [id="configuring-kiali-grafana_{context}"] == Configuring Kiali for Grafana -When you install Kiali and Grafana as part of {ProductName} the Operator configures the following by default: +When you install Kiali and Grafana as part of {SMProductName} the Operator configures the following by default: * Grafana is enabled as an external service for Kiali * Grafana authorization for the Kiali console @@ -75,7 +75,7 @@ spec: [id="configuring-kiali-jaeger_{context}"] == Configuring Kiali for Jaeger -When you install Kiali and Jaeger as part of {ProductName} the Operator configures the following by default: +When you install Kiali and Jaeger as part of {SMProductName} the Operator configures the following by default: * Jaeger is enabled as an external service for Kiali * Jaeger authorization for the Kiali console diff --git a/modules/ossm-configuring-the-threescale-wasm-auth-module.adoc b/modules/ossm-configuring-the-threescale-wasm-auth-module.adoc index e8382d8addc5..69fae1e26bd9 100644 --- a/modules/ossm-configuring-the-threescale-wasm-auth-module.adoc +++ b/modules/ossm-configuring-the-threescale-wasm-auth-module.adoc @@ -10,7 +10,7 @@ Cluster administrators on {product-title} can configure the `threescale-wasm-aut [id="the-service-mesh-extension_{context}"] == The Service Mesh extension -{ProductShortName} provides a xref:../../operators/understanding/crds/crd-extending-api-with-crds.adoc#crd-extending-api-with-crds[custom resource definition] to specify and apply Proxy-WASM extensions to sidecar proxies, known as xref:../../service_mesh/v2x/ossm-extensions.adoc#ossm-extensions[`ServiceMeshExtension`]. {ProductShortName} applies this custom resource to the set of workloads that require HTTP API management with 3scale. +{SMProductShortName} provides a xref:../../operators/understanding/crds/crd-extending-api-with-crds.adoc#crd-extending-api-with-crds[custom resource definition] to specify and apply Proxy-WASM extensions to sidecar proxies, known as xref:../../service_mesh/v2x/ossm-extensions.adoc#ossm-extensions[`ServiceMeshExtension`]. {SMProductShortName} applies this custom resource to the set of workloads that require HTTP API management with 3scale. [NOTE] ==== @@ -19,11 +19,11 @@ Configuring the WebAssembly extension is currently a manual process. Support for .Prerequisites -* Identify a Kubernetes workload and namespace on your {ProductShortName} deployment that you will apply this module. +* Identify a Kubernetes workload and namespace on your {SMProductShortName} deployment that you will apply this module. * You must have a 3scale tenant account. See link:https://www.3scale.net/signup[SaaS] or link:https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.11/html-single/installing_3scale/index#install-threescale-on-openshift-guide[3scale 2.11 On-Premises] with a matching service and relevant applications and metrics defined. * If you apply the module to the `productpage` microservice in the `bookinfo` namespace, see the xref:../../service_mesh/v1x/prepare-to-deploy-applications-ossm.html#ossm-tutorial-bookinfo-overview_deploying-applications-ossm-v1x[Bookinfo sample application]. ** The following example is the YAML format for the custom resource for `threescale-wasm-auth` module. -This example refers to the upstream Maistra version of {ProductShortName}, ServiceMeshExtension API. You must declare the namespace where the `threescale-wasm-auth` module is deployed, alongside a `WorkloadSelector` to identify the set of applications the module will apply to: +This example refers to the upstream Maistra version of {SMProductShortName}, ServiceMeshExtension API. You must declare the namespace where the `threescale-wasm-auth` module is deployed, alongside a `WorkloadSelector` to identify the set of applications the module will apply to: + [source,yaml] ---- diff --git a/modules/ossm-control-plane-cli.adoc b/modules/ossm-control-plane-cli.adoc index 947695ed4470..778a39d8bb9e 100644 --- a/modules/ossm-control-plane-cli.adoc +++ b/modules/ossm-control-plane-cli.adoc @@ -11,12 +11,12 @@ You can deploy a basic `ServiceMeshControlPlane` from the command line. .Prerequisites -* The {ProductName} Operator must be installed. +* The {SMProductName} Operator must be installed. * Access to the OpenShift CLI (`oc`). .Procedure -. 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/ossm-control-plane-deploy-1x.adoc b/modules/ossm-control-plane-deploy-1x.adoc index 028345b4398b..5cfe4624a8e9 100644 --- a/modules/ossm-control-plane-deploy-1x.adoc +++ b/modules/ossm-control-plane-deploy-1x.adoc @@ -4,7 +4,7 @@ :_content-type: PROCEDURE [id="ossm-control-plane-deploy-1x_{context}"] -= Deploying the {ProductName} control plane += Deploying the {SMProductName} control plane //// TODO - Flesh out how multitenancy affects this, link to control plate template topic. @@ -12,17 +12,17 @@ TODO - Flesh out how multitenancy affects this, link to control plate template t The `ServiceMeshControlPlane` resource defines the configuration to be used during installation. You can deploy the default configuration provided by Red Hat or customize the `ServiceMeshControlPlane` file to fit your business needs. -You can deploy the {ProductShortName} control plane by using the {product-title} web console or from the command line using the `oc` client tool. +You can deploy the {SMProductShortName} control plane by using the {product-title} web console or from the command line using the `oc` client tool. [id="ossm-control-plane-deploy-operatorhub_{context}"] == Deploying the control plane from the web console -Follow this procedure to deploy the {ProductName} control plane by using the web console. In this example, `istio-system` is the name of the control plane project. +Follow this procedure to deploy the {SMProductName} control plane by using the web console. In this example, `istio-system` is the name of the control plane project. .Prerequisites -* The {ProductName} Operator must be installed. -* Review the instructions for how to customize the {ProductName} installation. +* The {SMProductName} Operator must be installed. +* Review the instructions for how to customize the {SMProductName} installation. * An account with the `cluster-admin` role. .Procedure @@ -43,7 +43,7 @@ Follow this procedure to deploy the {ProductName} control plane by using the web . If necessary, select `istio-system` from the Project menu. You may have to wait a few moments for the Operators to be copied to the new project. -. Click the {ProductName} Operator. Under *Provided APIs*, the Operator provides links to create two resource types: +. Click the {SMProductName} Operator. Under *Provided APIs*, the Operator provides links to create two resource types: ** A `ServiceMeshControlPlane` resource ** A `ServiceMeshMemberRoll` resource @@ -53,27 +53,27 @@ Follow this procedure to deploy the {ProductName} control plane by using the web + [NOTE] ==== -For additional information about customizing the control plane, see customizing the {ProductName} installation. For production, you _must_ change the default Jaeger template. +For additional information about customizing the control plane, see customizing the {SMProductName} installation. For production, you _must_ change the default Jaeger template. ==== -. Click *Create* to create the control plane. The Operator creates pods, services, and {ProductShortName} control plane components based on your configuration parameters. +. Click *Create* to create the control plane. The Operator creates pods, services, and {SMProductShortName} control plane components based on your configuration parameters. . Click the *Istio Service Mesh Control Plane* tab. . Click the name of the new control plane. -. Click the *Resources* tab to see the {ProductName} control plane resources the Operator created and configured. +. Click the *Resources* tab to see the {SMProductName} control plane resources the Operator created and configured. [id="ossm-control-plane-deploy-cli_{context}"] == Deploying the control plane from the CLI -Follow this procedure to deploy the {ProductName} control plane the command line. +Follow this procedure to deploy the {SMProductName} control plane the command line. .Prerequisites -* The {ProductName} Operator must be installed. -* Review the instructions for how to customize the {ProductName} installation. +* The {SMProductName} Operator must be installed. +* Review the instructions for how to customize the {SMProductName} installation. * An account with the `cluster-admin` role. * Access to the OpenShift CLI (`oc`). @@ -93,7 +93,7 @@ $ oc login https://:6443 $ oc new-project istio-system ---- -. Create a `ServiceMeshControlPlane` file named `istio-installation.yaml` using the example found in "Customize the {ProductName} installation". You can customize the values as needed to match your use case. For production deployments you _must_ change the default Jaeger template. +. Create a `ServiceMeshControlPlane` file named `istio-installation.yaml` using the example found in "Customize the {SMProductName} installation". You can customize the values as needed to match your use case. For production deployments you _must_ change the default Jaeger template. . Run the following command to deploy the control plane: + diff --git a/modules/ossm-control-plane-deploy.adoc b/modules/ossm-control-plane-deploy.adoc index 46a621c34693..5b1105b7740b 100644 --- a/modules/ossm-control-plane-deploy.adoc +++ b/modules/ossm-control-plane-deploy.adoc @@ -2,10 +2,10 @@ // * service_mesh/v2x/installing-ossm.adoc [id="ossm-control-plane-deploy_{context}"] -= Creating the {ProductName} control plane += Creating the {SMProductName} control plane The `ServiceMeshControlPlane` resource defines the configuration to be used during installation. -You can deploy a basic installation of the {ProductShortName} control plane by using the {product-title} web console or from the command line using the `oc` client tool. +You can deploy a basic installation of the {SMProductShortName} control plane by using the {product-title} web console or from the command line using the `oc` client tool. -To get started, install a basic instance of {ProductShortName} with the following steps. You can customize the `ServiceMeshControlPlane` resource later. +To get started, install a basic instance of {SMProductShortName} with the following steps. You can customize the `ServiceMeshControlPlane` resource later. diff --git a/modules/ossm-control-plane-profiles.adoc b/modules/ossm-control-plane-profiles.adoc index 53dd77e3aec3..d3ca7a43da30 100644 --- a/modules/ossm-control-plane-profiles.adoc +++ b/modules/ossm-control-plane-profiles.adoc @@ -8,7 +8,7 @@ You can create reusable configurations with `ServiceMeshControlPlane` profiles. Individual users can extend the profiles they create with their own configurations. Profiles can also inherit configuration information from other profiles. For example, you can create an accounting control plane for the accounting team and a marketing control plane for the marketing team. If you create a development template and a production template, members of the marketing team and the accounting team can extend the development and production profiles with team-specific customization. -When you configure control plane profiles, which follow the same syntax as the `ServiceMeshControlPlane`, users inherit settings in a hierarchical fashion. The Operator is delivered with a `default` profile with default settings for {ProductName}. +When you configure control plane profiles, which follow the same syntax as the `ServiceMeshControlPlane`, users inherit settings in a hierarchical fashion. The Operator is delivered with a `default` profile with default settings for {SMProductName}. [id="ossm-create-configmap_{context}"] == Creating the ConfigMap @@ -17,7 +17,7 @@ To add custom profiles, you must create a `ConfigMap` named `smcp-templates` in .Prerequisites -* An installed, verified {ProductShortName} Operator. +* An installed, verified {SMProductShortName} Operator. * An account with the `cluster-admin` role. If you use {product-dedicated}, you must have an account with the `dedicated-admin` role. * Location of the Operator deployment. * Access to the OpenShift CLI (`oc`). diff --git a/modules/ossm-control-plane-remove.adoc b/modules/ossm-control-plane-remove.adoc index f035a8f5c560..416220863d3d 100644 --- a/modules/ossm-control-plane-remove.adoc +++ b/modules/ossm-control-plane-remove.adoc @@ -5,14 +5,14 @@ :_content-type: PROCEDURE [id="ossm-control-plane-remove_{context}"] -= Removing the {ProductName} control plane += Removing the {SMProductName} control plane -To uninstall {ProductShortName} from an existing {product-title} instance, you must first delete the control plane and the Operators. Then, you must run commands to manually remove residual resources. +To uninstall {SMProductShortName} from an existing {product-title} instance, you must first delete the control plane and the Operators. Then, you must run commands to manually remove residual resources. [id="ossm-control-plane-remove-operatorhub_{context}"] == Removing the control plane with the web console -You can remove the {ProductName} control plane by using the web console. +You can remove the {SMProductName} control plane by using the web console. .Procedure @@ -33,7 +33,7 @@ You can remove the {ProductName} control plane by using the web console. [id="ossm-control-plane-remove-cli_{context}"] == Removing the control plane from the CLI -You can remove the {ProductName} control plane by using the CLI. In this example, `istio-system` is the name of the control plane project. +You can remove the {SMProductName} control plane by using the CLI. In this example, `istio-system` is the name of the control plane project. .Procedure diff --git a/modules/ossm-control-plane-templates-1x.adoc b/modules/ossm-control-plane-templates-1x.adoc index 3c1c7f95834a..4b40c89a68ee 100644 --- a/modules/ossm-control-plane-templates-1x.adoc +++ b/modules/ossm-control-plane-templates-1x.adoc @@ -8,7 +8,7 @@ You can create reusable configurations with `ServiceMeshControlPlane` templates. Individual users can extend the templates they create with their own configurations. Templates can also inherit configuration information from other templates. For example, you can create an accounting control plane for the accounting team and a marketing control plane for the marketing team. If you create a development template and a production template, members of the marketing team and the accounting team can extend the development and production templates with team specific customization. -When you configure control plane templates, which follow the same syntax as the `ServiceMeshControlPlane`, users inherit settings in a hierarchical fashion. The Operator is delivered with a `default` template with default settings for {ProductName}. To add custom templates you must create a ConfigMap named `smcp-templates` in the `openshift-operators` project and mount the ConfigMap in the Operator container at `/usr/local/share/istio-operator/templates`. +When you configure control plane templates, which follow the same syntax as the `ServiceMeshControlPlane`, users inherit settings in a hierarchical fashion. The Operator is delivered with a `default` template with default settings for {SMProductName}. To add custom templates you must create a ConfigMap named `smcp-templates` in the `openshift-operators` project and mount the ConfigMap in the Operator container at `/usr/local/share/istio-operator/templates`. [id="ossm-create-configmap_{context}"] == Creating the ConfigMap @@ -21,7 +21,7 @@ Follow this procedure to create the ConfigMap. .Prerequisites -* An installed, verified {ProductShortName} Operator. +* An installed, verified {SMProductShortName} Operator. * An account with the `cluster-admin` role. * Location of the Operator deployment. * Access to the OpenShift CLI (`oc`). diff --git a/modules/ossm-control-plane-web.adoc b/modules/ossm-control-plane-web.adoc index 1ba72249771a..51f31f49e2f2 100644 --- a/modules/ossm-control-plane-web.adoc +++ b/modules/ossm-control-plane-web.adoc @@ -10,12 +10,12 @@ You can deploy a basic `ServiceMeshControlPlane` by using the web console. In t .Prerequisites -* The {ProductName} Operator must be installed. +* The {SMProductName} Operator must be installed. * An account with the `cluster-admin` role. .Procedure -. Log in to the {product-title} web console 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} web console as a user with the `cluster-admin` role. If you use {product-dedicated}, you must have an account with the `dedicated-admin` role. . Create a project named `istio-system`. + @@ -31,18 +31,18 @@ These steps use `istio-system` as an example, but you can deploy your control pl . Navigate to *Operators* -> *Installed Operators*. -. Click the {ProductName} Operator, then click *Istio Service Mesh Control Plane*. +. Click the {SMProductName} Operator, then click *Istio Service Mesh Control Plane*. . On the *Istio Service Mesh Control Plane* tab, click *Create ServiceMeshControlPlane*. . On the *Create ServiceMeshControlPlane* page, accept the default control plane version to take advantage of the features available in the most current version of the product. The version of the control plane determines the features available regardless of the version of the Operator. + -You can configure `ServiceMeshControlPlane` settings later. For more information, see Configuring {ProductName}. +You can configure `ServiceMeshControlPlane` settings later. For more information, see Configuring {SMProductName}. + -.. Click *Create*. The Operator creates pods, services, and {ProductShortName} control plane components based on your configuration parameters. +.. Click *Create*. The Operator creates pods, services, and {SMProductShortName} control plane components based on your configuration parameters. . To verify the control plane installed correctly, click the *Istio Service Mesh Control Plane* tab. + .. Click the name of the new control plane. + -.. Click the *Resources* tab to see the {ProductName} control plane resources the Operator created and configured. +.. Click the *Resources* tab to see the {SMProductName} control plane resources the Operator created and configured. diff --git a/modules/ossm-cr-example-1x.adoc b/modules/ossm-cr-example-1x.adoc index 48376f8c444e..8f7157cef7a0 100644 --- a/modules/ossm-cr-example-1x.adoc +++ b/modules/ossm-cr-example-1x.adoc @@ -3,18 +3,18 @@ // * service_mesh/v1x/customizing-installation-ossm.adoc [id="ossm-cr-example-1x_{context}"] -= {ProductName} custom resources += {SMProductName} custom resources [NOTE] ==== -The `istio-system` project is used as an example throughout the {ProductShortName} documentation, but you can use other projects as necessary. +The `istio-system` project is used as an example throughout the {SMProductShortName} documentation, but you can use other projects as necessary. ==== -A _custom resource_ allows you to extend the API in an {ProductName} project or cluster. When you deploy {ProductShortName} it creates a default `ServiceMeshControlPlane` that you can modify to change the project parameters. +A _custom resource_ allows you to extend the API in an {SMProductName} project or cluster. When you deploy {SMProductShortName} it creates a default `ServiceMeshControlPlane` that you can modify to change the project parameters. -The {ProductShortName} operator extends the API by adding the `ServiceMeshControlPlane` resource type, which enables you to create `ServiceMeshControlPlane` objects within projects. By creating a `ServiceMeshControlPlane` object, you instruct the Operator to install a {ProductShortName} control plane into the project, configured with the parameters you set in the `ServiceMeshControlPlane` object. +The {SMProductShortName} operator extends the API by adding the `ServiceMeshControlPlane` resource type, which enables you to create `ServiceMeshControlPlane` objects within projects. By creating a `ServiceMeshControlPlane` object, you instruct the Operator to install a {SMProductShortName} control plane into the project, configured with the parameters you set in the `ServiceMeshControlPlane` object. -This example `ServiceMeshControlPlane` definition contains all of the supported parameters and deploys {ProductName} {ProductVersion} images based on Red Hat Enterprise Linux (RHEL). +This example `ServiceMeshControlPlane` definition contains all of the supported parameters and deploys {SMProductName} {SMProductVersion1x} images based on Red Hat Enterprise Linux (RHEL). [IMPORTANT] ==== diff --git a/modules/ossm-cr-example.adoc b/modules/ossm-cr-example.adoc index 62bb5a08ab27..572d43106455 100644 --- a/modules/ossm-cr-example.adoc +++ b/modules/ossm-cr-example.adoc @@ -32,7 +32,7 @@ The following table lists the top-level parameters for the `ServiceMeshControlPl |For more information, see Table 3. |=== -The following table lists the specifications for the `ServiceMeshControlPlane` resource. Changing these parameters configures {ProductName} components. +The following table lists the specifications for the `ServiceMeshControlPlane` resource. Changing these parameters configures {SMProductName} components. .`ServiceMeshControlPlane` resource spec |=== diff --git a/modules/ossm-cr-parameters.adoc b/modules/ossm-cr-parameters.adoc index 519ccad1e9ce..d88f9407b139 100644 --- a/modules/ossm-cr-parameters.adoc +++ b/modules/ossm-cr-parameters.adoc @@ -10,5 +10,5 @@ The following examples illustrate use of the `ServiceMeshControlPlane` parameter [IMPORTANT] ==== -The resources you configure for {ProductName} with these parameters, including CPUs, memory, and the number of pods, are based on the configuration of your {product-title} cluster. Configure these parameters based on the available resources in your current cluster configuration. +The resources you configure for {SMProductName} with these parameters, including CPUs, memory, and the number of pods, are based on the configuration of your {product-title} cluster. Configure these parameters based on the available resources in your current cluster configuration. ==== diff --git a/modules/ossm-cr-profiles.adoc b/modules/ossm-cr-profiles.adoc index 5f7b984fc4b0..6af4ccf9ff7f 100644 --- a/modules/ossm-cr-profiles.adoc +++ b/modules/ossm-cr-profiles.adoc @@ -5,7 +5,7 @@ [id="ossm-cr-profiles_{context}"] = profiles parameters -You can create reusable configurations with `ServiceMeshControlPlane` object profiles. If you do not configure the `profile` setting, {ProductName} uses the default profile. +You can create reusable configurations with `ServiceMeshControlPlane` object profiles. If you do not configure the `profile` setting, {SMProductName} uses the default profile. Here is an example that illustrates the `spec.profiles` parameter for the `ServiceMeshControlPlane` object: diff --git a/modules/ossm-cr-threescale-1x.adoc b/modules/ossm-cr-threescale-1x.adoc index 792be2a6ca61..98e840bd6fbc 100644 --- a/modules/ossm-cr-threescale-1x.adoc +++ b/modules/ossm-cr-threescale-1x.adoc @@ -6,7 +6,7 @@ = 3scale configuration -Here is an example that illustrates the 3scale Istio Adapter parameters for the {ProductName} custom resource and a description of the available parameters with appropriate values. +Here is an example that illustrates the 3scale Istio Adapter parameters for the {SMProductName} custom resource and a description of the available parameters with appropriate values. .Example 3scale parameters [source,yaml] diff --git a/modules/ossm-deploy-multi-mesh.adoc b/modules/ossm-deploy-multi-mesh.adoc index 2377785785c7..f0abf24e8500 100644 --- a/modules/ossm-deploy-multi-mesh.adoc +++ b/modules/ossm-deploy-multi-mesh.adoc @@ -7,6 +7,6 @@ _Federation_ is a deployment model that lets you share services and workloads between separate meshes managed in distinct administrative domains. -The Istio multi-cluster model requires a high level of trust between meshes and remote access to all Kubernetes API servers on which the individual meshes reside. {ProductName} federation takes an opinionated approach to a multi-cluster implementation of Service Mesh that assumes _minimal_ trust between meshes. +The Istio multi-cluster model requires a high level of trust between meshes and remote access to all Kubernetes API servers on which the individual meshes reside. {SMProductName} federation takes an opinionated approach to a multi-cluster implementation of Service Mesh that assumes _minimal_ trust between meshes. A _federated mesh_ is a group of meshes behaving as a single mesh. The services in each mesh can be unique services, for example a mesh adding services by importing them from another mesh, can provide additional workloads for the same services across the meshes, providing high availability, or a combination of both. All meshes that are joined into a federated mesh remain managed individually, and you must explicitly configure which services are exported to and imported from other meshes in the federation. Support functions such as certificate generation, metrics and trace collection remain local in their respective meshes. diff --git a/modules/ossm-deploy-multitenant.adoc b/modules/ossm-deploy-multitenant.adoc index c1652711d39f..13b314cc25e0 100644 --- a/modules/ossm-deploy-multitenant.adoc +++ b/modules/ossm-deploy-multitenant.adoc @@ -4,12 +4,12 @@ [id="ossm-deploy-multitenant_{context}"] = Multitenant deployment model -{ProductName} installs a `ServiceMeshControlPlane` that is configured for multitenancy by default. {ProductName} uses a multitenant Operator to manage the control plane lifecycle. Within a mesh, namespaces are used for tenancy. +{SMProductName} installs a `ServiceMeshControlPlane` that is configured for multitenancy by default. {SMProductName} uses a multitenant Operator to manage the control plane lifecycle. Within a mesh, namespaces are used for tenancy. -{ProductName} uses `ServiceMeshControlPlane` resources to manage mesh installations, whose scope is limited by default to namespace that contains the resource. You use `ServiceMeshMemberRoll` and `ServiceMeshMember` resources to include additional namespaces into the mesh. A namespace can only be included in a single mesh, and multiple meshes can be installed in a single OpenShift cluster. +{SMProductName} uses `ServiceMeshControlPlane` resources to manage mesh installations, whose scope is limited by default to namespace that contains the resource. You use `ServiceMeshMemberRoll` and `ServiceMeshMember` resources to include additional namespaces into the mesh. A namespace can only be included in a single mesh, and multiple meshes can be installed in a single OpenShift cluster. -Typical service mesh deployments use a single control plane to configure communication between services in the mesh. {ProductName} supports “soft multitenancy”, where there is one control plane and one mesh per tenant, and there can be multiple independent control planes within the cluster. Multitenant deployments specify the projects that can access the {ProductShortName} and isolate the {ProductShortName} from other control plane instances. +Typical service mesh deployments use a single control plane to configure communication between services in the mesh. {SMProductName} supports “soft multitenancy”, where there is one control plane and one mesh per tenant, and there can be multiple independent control planes within the cluster. Multitenant deployments specify the projects that can access the {SMProductShortName} and isolate the {SMProductShortName} from other control plane instances. -The cluster administrator gets control and visibility across all the Istio control planes, while the tenant administrator only gets control over their specific {ProductShortName}, Kiali, and Jaeger instances. +The cluster administrator gets control and visibility across all the Istio control planes, while the tenant administrator only gets control over their specific {SMProductShortName}, Kiali, and Jaeger instances. You can grant a team permission to deploy its workloads only to a given namespace or set of namespaces. If granted the `mesh-user` role by the service mesh administrator, users can create a `ServiceMeshMember` resource to add namespaces to the `ServiceMeshMemberRoll`. diff --git a/modules/ossm-deploy-single-tenant.adoc b/modules/ossm-deploy-single-tenant.adoc index 430fc6be903c..981b4736c2d2 100644 --- a/modules/ossm-deploy-single-tenant.adoc +++ b/modules/ossm-deploy-single-tenant.adoc @@ -6,4 +6,4 @@ In Istio, a tenant is a group of users that share common access and privileges for a set of deployed workloads. You can use tenants to provide a level of isolation between different teams. You can segregate access to different tenants using `NetworkPolicies`, `AuthorizationPolicies`, and `exportTo` annotations on istio.io or service resources. -Single tenant, cluster-wide control plane configurations are deprecated as of {ProductName} version 1.0. {ProductName} defaults to a multitenant model. +Single tenant, cluster-wide control plane configurations are deprecated as of {SMProductName} version 1.0. {SMProductName} defaults to a multitenant model. diff --git a/modules/ossm-distr-tracing.adoc b/modules/ossm-distr-tracing.adoc index bb071adff2ef..ce6a4fa1afb8 100644 --- a/modules/ossm-distr-tracing.adoc +++ b/modules/ossm-distr-tracing.adoc @@ -9,4 +9,4 @@ This module is included in the following assemblies: Distributed tracing is the process of tracking the performance of individual services in an application by tracing the path of the service calls in the application. Each time a user takes action in an application, a request is executed that might require many services to interact to produce a response. The path of this request is called a distributed transaction. -{ProductName} uses {DTProductName} to allow developers to view call flows in a microservice application. +{SMProductName} uses {DTProductName} to allow developers to view call flows in a microservice application. diff --git a/modules/ossm-extensions-wasm-deploy.adoc b/modules/ossm-extensions-wasm-deploy.adoc index d6089ee173f4..aa54ca9a7255 100644 --- a/modules/ossm-extensions-wasm-deploy.adoc +++ b/modules/ossm-extensions-wasm-deploy.adoc @@ -2,7 +2,7 @@ [id="ossm-extensions-deploy_{context}"] = Deploying extensions -{ProductName} extensions can be enabled using the `ServiceMeshExtension` resource. In this example, `istio-system` is the name of the control plane project. +{SMProductName} extensions can be enabled using the `ServiceMeshExtension` resource. In this example, `istio-system` is the name of the control plane project. .Procedure diff --git a/modules/ossm-federation-across-cluster.adoc b/modules/ossm-federation-across-cluster.adoc index 38c1838a5c12..e4c59e4414d1 100644 --- a/modules/ossm-federation-across-cluster.adoc +++ b/modules/ossm-federation-across-cluster.adoc @@ -16,7 +16,7 @@ If the cluster runs on bare metal and fully supports `LoadBalancer` services, th If the cluster does not support `LoadBalancer` services, using a `NodePort` service could be an option if the nodes are accessible from the cluster running the other mesh. In the `ServiceMeshPeer` object, specify the IP addresses of the nodes in the `.spec.remote.addresses` field and the service's node ports in the `.spec.remote.discoveryPort` and `.spec.remote.servicePort` fields. == Exposing the federation ingress on Amazon Web Services (AWS) -By default, LoadBalancer services in clusters running on AWS do not support L4 load balancing. In order for {ProductName} federation to operate correctly, the following annotation must be added to the ingress gateway service: +By default, LoadBalancer services in clusters running on AWS do not support L4 load balancing. In order for {SMProductName} federation to operate correctly, the following annotation must be added to the ingress gateway service: service.beta.kubernetes.io/aws-load-balancer-type: nlb diff --git a/modules/ossm-federation-checklist.adoc b/modules/ossm-federation-checklist.adoc index f7c77406c106..ccc3aac48b7e 100644 --- a/modules/ossm-federation-checklist.adoc +++ b/modules/ossm-federation-checklist.adoc @@ -12,7 +12,7 @@ Federating services meshes involves the following activities: ** [ ] Configure the load balancers supporting the services associated with the federation gateways to support raw TLS traffic. -* [ ] Installing the {ProductName} version 2.1 Operator in each of your clusters. +* [ ] Installing the {SMProductName} version 2.1 Operator in each of your clusters. * [ ] Deploying a version 2.1 `ServiceMeshControlPlane` to each of your clusters. diff --git a/modules/ossm-federation-config-smcp.adoc b/modules/ossm-federation-config-smcp.adoc index c0c9f7ced32e..465dfa25bc3a 100644 --- a/modules/ossm-federation-config-smcp.adoc +++ b/modules/ossm-federation-config-smcp.adoc @@ -304,7 +304,7 @@ Follow this procedure to edit the `ServiceMeshControlPlane` with the {product-ti . Click the *Project* menu and select the project where you installed the control plane. For example, `red-mesh-system`. -. Click the {ProductName} Operator. +. Click the {SMProductName} Operator. . On the *Istio Service Mesh Control Plane* tab, click the name of your `ServiceMeshControlPlane`, for example `red-mesh`. diff --git a/modules/ossm-federation-create-export.adoc b/modules/ossm-federation-create-export.adoc index d9672f6d28ef..02a27119eeea 100644 --- a/modules/ossm-federation-create-export.adoc +++ b/modules/ossm-federation-create-export.adoc @@ -30,7 +30,7 @@ Follow this procedure to create an `ExportServiceSet` with the web console. This . Log in to the {product-title} web console as a user with the cluster-admin role. . Navigate to *Operators* → *Installed Operators*. . Click the *Project* menu and select the project where you installed the control plane for the mesh that will export services. For example, `red-mesh-system`. -. Click the {ProductName} Operator, then click *Istio Service Mesh ExportedServiceSet*. +. Click the {SMProductName} Operator, then click *Istio Service Mesh ExportedServiceSet*. . On the *Istio Service Mesh ExportedServiceSet* tab, click *Create ExportedServiceSet*. . On the *Create ExportedServiceSet* page, click *YAML* to modify your configuration. . Modify the default configuration with values for your export. diff --git a/modules/ossm-federation-create-import.adoc b/modules/ossm-federation-create-import.adoc index 486124f45a19..ad33a08483a2 100644 --- a/modules/ossm-federation-create-import.adoc +++ b/modules/ossm-federation-create-import.adoc @@ -30,7 +30,7 @@ Follow this procedure to create an `ImportServiceSet` with the web console. This . Log in to the {product-title} web console as a user with the cluster-admin role. . Navigate to *Operators* → *Installed Operators*. . Click the *Project* menu and select the project where you installed the control plane for the mesh you want to import services into. For example, `green-mesh-system`. -. Click the {ProductName} Operator, then click *Istio Service Mesh ImportServiceSet*. +. Click the {SMProductName} Operator, then click *Istio Service Mesh ImportServiceSet*. . On the *Istio Service Mesh ImportServiceSet* tab, click *Create ImportServiceSet*. . On the *Create ImportServiceSet* page, click *YAML* to modify your configuration. . Modify the default configuration with values for your import. diff --git a/modules/ossm-federation-create-meshPeer.adoc b/modules/ossm-federation-create-meshPeer.adoc index 8c51fdaf50e7..a70c3d75d79b 100644 --- a/modules/ossm-federation-create-meshPeer.adoc +++ b/modules/ossm-federation-create-meshPeer.adoc @@ -24,7 +24,7 @@ Follow this procedure to create a `ServiceMeshPeer` resource from the console. T . Log in to the {product-title} web console as a user with the cluster-admin role. . Navigate to *Operators* → *Installed Operators*. . Click the *Project* menu and select the project where you installed the control plane for the mesh that is creating the `ServiceMeshPeer` resource. For example, `red-mesh-system`. -. Click the {ProductName} Operator, then click *Istio Service Mesh ServiceMeshPeer*. +. Click the {SMProductName} Operator, then click *Istio Service Mesh ServiceMeshPeer*. . On the *Istio Service Mesh ServiceMeshPeer* tab, click *Create ServiceMeshPeer*. . On the *Create ServiceMeshPeer* page, click *YAML* to modify your configuration. . Modify the default configuration with values for the mesh federation between the peers. diff --git a/modules/ossm-federation-features.adoc b/modules/ossm-federation-features.adoc index 61c76c1f2ed4..51618891e691 100644 --- a/modules/ossm-federation-features.adoc +++ b/modules/ossm-federation-features.adoc @@ -7,7 +7,7 @@ This module included in the following assemblies: = Federation features [role="_abstract"] -Features of the {ProductName} federated approach to joining meshes include the following: +Features of the {SMProductName} federated approach to joining meshes include the following: * Supports common root certificates for each mesh. * Supports different root certificates for each mesh. diff --git a/modules/ossm-federation-limitations.adoc b/modules/ossm-federation-limitations.adoc index 21e1bcbc7a1a..5141f6ceede3 100644 --- a/modules/ossm-federation-limitations.adoc +++ b/modules/ossm-federation-limitations.adoc @@ -6,7 +6,7 @@ This module included in the following assemblies: [id="ossm-federation-limitations_{context}"] = Federation limitations -The {ProductName} federated approach to joining meshes has the following limitations: +The {SMProductName} federated approach to joining meshes has the following limitations: * Federation of meshes is not supported on OpenShift Dedicated. * Federation of meshes is not supported on Microsoft Azure Red Hat OpenShift (ARO). diff --git a/modules/ossm-federation-overview.adoc b/modules/ossm-federation-overview.adoc index 69b765c3cf86..2c0283c6131f 100644 --- a/modules/ossm-federation-overview.adoc +++ b/modules/ossm-federation-overview.adoc @@ -7,9 +7,9 @@ This module included in the following assemblies: [id="ossm-federation-overview_{context}"] = Federation overview -Federation is a set of features that let you connect services between separate meshes, allowing the use of {ProductShortName} features such as authentication, authorization, and traffic management across multiple, distinct administrative domains. +Federation is a set of features that let you connect services between separate meshes, allowing the use of {SMProductShortName} features such as authentication, authorization, and traffic management across multiple, distinct administrative domains. -Implementing a federated mesh lets you run, manage, and observe a single service mesh running across multiple OpenShift clusters. {ProductName} federation takes an opinionated approach to a multi-cluster implementation of Service Mesh that assumes _minimal_ trust between meshes. +Implementing a federated mesh lets you run, manage, and observe a single service mesh running across multiple OpenShift clusters. {SMProductName} federation takes an opinionated approach to a multi-cluster implementation of Service Mesh that assumes _minimal_ trust between meshes. Service Mesh federation assumes that each mesh is managed individually and retains its own administrator. The default behavior is that no communication is permitted and no information is shared between meshes. The sharing of information between meshes is on an explicit opt-in basis. Nothing is shared in a federated mesh unless it has been configured for sharing. Support functions such as certificate generation, metrics and trace collection remain local in their respective meshes. diff --git a/modules/ossm-federation-prerequisites.adoc b/modules/ossm-federation-prerequisites.adoc index 8dd07c7198ff..3713f471529d 100644 --- a/modules/ossm-federation-prerequisites.adoc +++ b/modules/ossm-federation-prerequisites.adoc @@ -6,10 +6,10 @@ This module included in the following assemblies: [id="ossm-federation-prerequisites_{context}"] = Federation prerequisites -The {ProductName} federated approach to joining meshes has the following prerequisites: +The {SMProductName} federated approach to joining meshes has the following prerequisites: * Two or more {product-title} 4.6 or above clusters. -* Federation was introduced in {ProductName} 2.1. You must have the {ProductName} 2.1 Operator installed on each mesh that you want to federate. +* Federation was introduced in {SMProductName} 2.1. You must have the {SMProductName} 2.1 Operator installed on each mesh that you want to federate. * You must have a version 2.1 `ServiceMeshControlPlane` deployed on each mesh that you want to federate. * You must configure the load balancers supporting the services associated with the federation gateways to support raw TLS traffic. Federation traffic consists of HTTPS for discovery and raw encrypted TCP for service traffic. * Services that you want to expose to another mesh should be deployed before you can export and import them. However, this is not a strict requirement. You can specify service names that do not yet exist for export/import. When you deploy the services named in the `ExportedServiceSet` and `ImportedServiceSet` they will be automatically made available for export/import. diff --git a/modules/ossm-install-kiali.adoc b/modules/ossm-install-kiali.adoc index 529eb1e500d7..ea9653a1d3c0 100644 --- a/modules/ossm-install-kiali.adoc +++ b/modules/ossm-install-kiali.adoc @@ -7,7 +7,7 @@ [id="ossm-install-kiali_{context}"] = Installing the Kiali Operator -You must install the Kiali Operator for the {ProductName} Operator to install the control plane. +You must install the Kiali Operator for the {SMProductName} Operator to install the control plane. [WARNING] ==== diff --git a/modules/ossm-install-ossm-operator.adoc b/modules/ossm-install-ossm-operator.adoc index b6a6269f169d..83639e54cc7a 100644 --- a/modules/ossm-install-ossm-operator.adoc +++ b/modules/ossm-install-ossm-operator.adoc @@ -7,12 +7,12 @@ [id="ossm-install-ossm-operator_{context}"] = Installing the Operators -To install {ProductName}, install following Operators in this order. Repeat the procedure for each Operator. +To install {SMProductName}, install following Operators in this order. Repeat the procedure for each Operator. * OpenShift Elasticsearch * {JaegerName} * Kiali -* {ProductName} +* {SMProductName} .Procedure @@ -34,9 +34,9 @@ Elasticsearch Operator. . On the *Install Operator* page, select installation options. .. For the OpenShift Elasticsearch Operator, in the *Update Channel* section, select *stable-5.x*. -.. For the {JaegerName}, Kiali, and {ProductName} Operators, accept the defaults. +.. For the {JaegerName}, Kiali, and {SMProductName} Operators, accept the defaults. + -The {JaegerName}, Kiali and {ProductName} Operators are installed in the `openshift-operators` namespace. The OpenShift Elasticsearch Operator is installed in the `openshift-operators-redhat` namespace. +The {JaegerName}, Kiali and {SMProductName} Operators are installed in the `openshift-operators` namespace. The OpenShift Elasticsearch Operator is installed in the `openshift-operators-redhat` namespace. . Click *Install*. Wait until the Operator has installed before repeating the steps for the next Operator in the list. diff --git a/modules/ossm-installation-activities.adoc b/modules/ossm-installation-activities.adoc index c553c35ebacb..472a78bc69cb 100644 --- a/modules/ossm-installation-activities.adoc +++ b/modules/ossm-installation-activities.adoc @@ -8,9 +8,9 @@ [id="ossm-installation-activities_{context}"] = Operator overview -{ProductName} requires the following four Operators: +{SMProductName} requires the following four Operators: * *OpenShift Elasticsearch* - (Optional) Provides database storage for tracing and logging with the {JaegerShortName}. It is based on the open source link:https://www.elastic.co/[Elasticsearch] project. * *{JaegerName}* - Provides distributed tracing to monitor and troubleshoot transactions in complex distributed systems. It is based on the open source link:https://www.jaegertracing.io/[Jaeger] project. * *Kiali* - Provides observability for your service mesh. Allows you to view configurations, monitor traffic, and analyze traces in a single console. It is based on the open source link:https://www.kiali.io/[Kiali] project. -* *{ProductName}* - Allows you to connect, secure, control, and observe the microservices that comprise your applications. The {ProductShortName} Operator defines and monitors the `ServiceMeshControlPlane` resources that manage the deployment, updating, and deletion of the {ProductShortName} components. It is based on the open source link:https://istio.io/[Istio] project. +* *{SMProductName}* - Allows you to connect, secure, control, and observe the microservices that comprise your applications. The {SMProductShortName} Operator defines and monitors the `ServiceMeshControlPlane` resources that manage the deployment, updating, and deletion of the {SMProductShortName} components. It is based on the open source link:https://istio.io/[Istio] project. diff --git a/modules/ossm-jaeger-accessing-console.adoc b/modules/ossm-jaeger-accessing-console.adoc index 9e5ded8ac575..364502d6a37f 100644 --- a/modules/ossm-jaeger-accessing-console.adoc +++ b/modules/ossm-jaeger-accessing-console.adoc @@ -8,7 +8,7 @@ Module included in the following assemblies: [id="ossm-accessing-jaeger-console_{context}"] = Accessing the Jaeger console -To access the Jaeger console you must have {ProductName} installed, {JaegerName} installed and configured. +To access the Jaeger console you must have {SMProductName} installed, {JaegerName} installed and configured. The installation process creates a route to access the Jaeger console. @@ -39,7 +39,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/ossm-jaeger-config-elasticsearch-v1x.adoc b/modules/ossm-jaeger-config-elasticsearch-v1x.adoc index cf13ad74b8a4..73e74214c0d4 100644 --- a/modules/ossm-jaeger-config-elasticsearch-v1x.adoc +++ b/modules/ossm-jaeger-config-elasticsearch-v1x.adoc @@ -8,7 +8,7 @@ The default Jaeger deployment strategy uses the `all-in-one` template so that the installation can be completed using minimal resources. However, because the `all-in-one` template uses in-memory storage, it is only recommended for development, demo, or testing purposes and should NOT be used for production environments. -If you are deploying {ProductShortName} and Jaeger in a production environment you must change the template to the `production-elasticsearch` template, which uses Elasticsearch for Jaeger's storage needs. +If you are deploying {SMProductShortName} and Jaeger in a production environment you must change the template to the `production-elasticsearch` template, which uses Elasticsearch for Jaeger's storage needs. Elasticsearch is a memory intensive application. The initial set of nodes specified in the default {product-title} installation may not be large enough to support the Elasticsearch cluster. You should modify the default Elasticsearch configuration to match your use case and the resources you have requested for your {product-title} installation. You can adjust both the CPU and memory limits for each component by modifying the resources block with valid CPU and memory values. Additional nodes must be added to the cluster if you want to run with the recommended amount (or more) of memory. Ensure that you do not exceed the resources requested for your {product-title} installation. @@ -45,7 +45,7 @@ spec: |tracing: enabled: -|This parameter enables/disables tracing in {ProductShortName}. Jaeger is installed by default. +|This parameter enables/disables tracing in {SMProductShortName}. Jaeger is installed by default. |`true`/`false` |`true` | @@ -115,7 +115,7 @@ Minimum deployment = 16Gi* . Navigate to *Operators* -> *Installed Operators*. -. Click the {ProductName} Operator. +. Click the {SMProductName} Operator. . Click the *Istio Service Mesh Control Plane* tab. diff --git a/modules/ossm-jaeger-config-es-cleaner-v1x.adoc b/modules/ossm-jaeger-config-es-cleaner-v1x.adoc index 43f09f493ab4..415eebb1293e 100644 --- a/modules/ossm-jaeger-config-es-cleaner-v1x.adoc +++ b/modules/ossm-jaeger-config-es-cleaner-v1x.adoc @@ -5,7 +5,7 @@ [id="ossm-jaeger-config-es-cleaner-v1x_{context}"] = Configuring the Elasticsearch index cleaner job -When the {ProductShortName} Operator creates the `ServiceMeshControlPlane` it also creates the custom resource (CR) for Jaeger. The {JaegerName} Operator then uses this CR when creating Jaeger instances. +When the {SMProductShortName} Operator creates the `ServiceMeshControlPlane` it also creates the custom resource (CR) for Jaeger. The {JaegerName} Operator then uses this CR when creating Jaeger instances. When using Elasticsearch storage, by default a job is created to clean old traces from it. To configure the options for this job, you edit the Jaeger custom resource (CR), to customize it for your use case. The relevant options are listed below. diff --git a/modules/ossm-jaeger-service-mesh.adoc b/modules/ossm-jaeger-service-mesh.adoc index 1a8e16495bfd..585b8dbb9af7 100644 --- a/modules/ossm-jaeger-service-mesh.adoc +++ b/modules/ossm-jaeger-service-mesh.adoc @@ -9,10 +9,10 @@ This CONCEPT module included in the following assemblies: Installing the {JaegerShortName} with the Service Mesh on {product-title} differs from community Jaeger installations in multiple ways. These modifications are sometimes necessary to resolve issues, provide additional features, or to handle differences when deploying on {product-title}. -* Distributed tracing has been enabled by default for {ProductShortName}. -* Ingress has been enabled by default for {ProductShortName}. +* Distributed tracing has been enabled by default for {SMProductShortName}. +* Ingress has been enabled by default for {SMProductShortName}. * The name for the Zipkin port name has changed to `jaeger-collector-zipkin` (from `http`) * Jaeger uses Elasticsearch for storage by default when you select either the `production` or `streaming` deployment option. -* The community version of Istio provides a generic "tracing" route. {ProductName} uses a "jaeger" route that is installed by the {JaegerName} 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. +* The community version of Istio provides a generic "tracing" route. {SMProductName} uses a "jaeger" route that is installed by the {JaegerName} Operator and is already protected by OAuth. +* {SMProductName} uses a sidecar for the Envoy proxy, and Jaeger also uses a sidecar, for the Jaeger agent. These two sidecars are configured separately and should not be confused with each other. The proxy sidecar creates spans related to the pod's ingress and egress traffic. The agent sidecar receives the spans emitted by the application and sends them to the Jaeger Collector. diff --git a/modules/ossm-kiali-accessing-console.adoc b/modules/ossm-kiali-accessing-console.adoc index 631c9c9837bd..e679a5ebf76c 100644 --- a/modules/ossm-kiali-accessing-console.adoc +++ b/modules/ossm-kiali-accessing-console.adoc @@ -10,7 +10,7 @@ Module included in the following assemblies: You can view your application's topology, health, and metrics in the Kiali console. If your service is experiencing problems, the Kiali console lets you view the data flow through your service. You can view insights about the mesh components at different levels, including abstract applications, services, and workloads. Kiali also provides an interactive graph view of your namespace in real time. -To access the Kiali console you must have {ProductName} installed, Kiali installed and configured. +To access the Kiali console you must have {SMProductName} installed, Kiali installed and configured. The installation process creates a route to access the Kiali console. diff --git a/modules/ossm-kiali-architecture.adoc b/modules/ossm-kiali-architecture.adoc index eda0ebf9785f..c5ae4b32f6d9 100644 --- a/modules/ossm-kiali-architecture.adoc +++ b/modules/ossm-kiali-architecture.adoc @@ -17,10 +17,10 @@ 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 are 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. +* *Prometheus* - A dedicated Prometheus instance is included as part of the {SMProductName} installation. When Istio telemetry is enabled, metrics data are 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) 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. -* *Jaeger* - Jaeger is optional, but is installed by default as part of the {ProductName} installation. When you install the {JaegerShortName} as part of the default {ProductName} installation, the Kiali console includes a tab to display distributed tracing data. Note that tracing data will not be available if you disable Istio's distributed tracing feature. Also note that user must have access to the namespace where the control plane is installed to view tracing data. +* *Jaeger* - Jaeger is optional, but is installed by default as part of the {SMProductName} installation. When you install the {JaegerShortName} as part of the default {SMProductName} installation, the Kiali console includes a tab to display distributed tracing data. Note that tracing data will not be available if you disable Istio's distributed tracing feature. Also note that user must have access to the namespace where the control plane is installed to view tracing data. -* *Grafana* - Grafana is optional, but is installed by default as part of the {ProductName} installation. When available, the metrics pages of Kiali display links to direct the user to the same metric in Grafana. Note that user must have access to the namespace where the control plane is installed to view links to the Grafana dashboard and view Grafana data. +* *Grafana* - Grafana is optional, but is installed by default as part of the {SMProductName} installation. When available, the metrics pages of Kiali display links to direct the user to the same metric in Grafana. Note that user must have access to the namespace where the control plane is installed to view links to the Grafana dashboard and view Grafana data. diff --git a/modules/ossm-kiali-overview.adoc b/modules/ossm-kiali-overview.adoc index 30e4ae37a065..e9f9fc0f9e31 100644 --- a/modules/ossm-kiali-overview.adoc +++ b/modules/ossm-kiali-overview.adoc @@ -8,8 +8,8 @@ This CONCEPT module included in the following assemblies: [id="ossm-kiali-overview_{context}"] = Kiali overview -Kiali provides observability into the {ProductShortName} running on {product-title}. Kiali helps you define, validate, and observe your Istio service mesh. It helps you to understand the structure of your service mesh by inferring the topology, and also provides information about the health of your service mesh. +Kiali provides observability into the {SMProductShortName} running on {product-title}. Kiali helps you define, validate, and observe your Istio service mesh. It helps you to understand the structure of your service mesh by inferring the topology, and also provides information about the health of your service mesh. Kiali provides an interactive graph view of your namespace in real time that provides visibility into features like circuit breakers, request rates, latency, and even graphs of traffic flows. Kiali offers insights about components at different levels, from Applications to Services and Workloads, and can display the interactions with contextual information and charts on the selected graph node or edge. Kiali also provides the ability to validate your Istio configurations, such as gateways, destination rules, virtual services, mesh policies, and more. Kiali provides detailed metrics, and a basic Grafana integration is available for advanced queries. Distributed tracing is provided by integrating Jaeger into the Kiali console. -Kiali is installed by default as part of the {ProductName}. +Kiali is installed by default as part of the {SMProductName}. diff --git a/modules/ossm-kiali-service-mesh.adoc b/modules/ossm-kiali-service-mesh.adoc index 081c1e076448..d3fa1268731b 100644 --- a/modules/ossm-kiali-service-mesh.adoc +++ b/modules/ossm-kiali-service-mesh.adoc @@ -14,4 +14,4 @@ Installing Kiali via the Service Mesh on {product-title} differs from community * Ingress has been enabled by default. * Updates have been made to the Kiali ConfigMap. * Updates have been made to the ClusterRole settings for Kiali. -* Do not edit the ConfigMap or the Kiali custom resource files as those changes might be overwritten by the {ProductShortName} or Kiali Operators. All configuration for Kiali running on {ProductName} is done in the `ServiceMeshControlPlane` custom resource file and there are limited configuration options. Updating the Operator files should be restricted to those users with `cluster-admin` privileges. If you use {product-dedicated}, updating the operator files should be restricted to those users with `dedicated-admin` privileges. +* Do not edit the ConfigMap or the Kiali custom resource files as those changes might be overwritten by the {SMProductShortName} or Kiali Operators. All configuration for Kiali running on {SMProductName} is done in the `ServiceMeshControlPlane` custom resource file and there are limited configuration options. Updating the Operator files should be restricted to those users with `cluster-admin` privileges. If you use {product-dedicated}, updating the operator files should be restricted to those users with `dedicated-admin` privileges. diff --git a/modules/ossm-member-roll-create.adoc b/modules/ossm-member-roll-create.adoc index a0b23cd1cef3..a01c8649a965 100644 --- a/modules/ossm-member-roll-create.adoc +++ b/modules/ossm-member-roll-create.adoc @@ -5,7 +5,7 @@ :_content-type: PROCEDURE [id="ossm-member-roll-create_{context}"] -= Creating the {ProductName} member roll += Creating the {SMProductName} member roll The `ServiceMeshMemberRoll` lists the projects that belong to the control plane. Only projects listed in the `ServiceMeshMemberRoll` are affected by the control plane. A project does not belong to a service mesh until you add it to the member roll for a particular control plane deployment. @@ -14,10 +14,10 @@ You must create a `ServiceMeshMemberRoll` resource named `default` in the same p [id="ossm-member-roll-create-console_{context}"] == Creating the member roll from the web console -You can add one or more projects to the {ProductShortName} member roll from the web console. In this example, `istio-system` is the name of the control plane project. +You can add one or more projects to the {SMProductShortName} member roll from the web console. In this example, `istio-system` is the name of the control plane project. .Prerequisites -* An installed, verified {ProductName} Operator. +* An installed, verified {SMProductName} Operator. * List of existing projects to add to the service mesh. .Procedure @@ -36,7 +36,7 @@ You can add one or more projects to the {ProductShortName} member roll from the . Click the *Project* menu and choose the project where your `ServiceMeshControlPlane` resource is deployed from the list, for example `istio-system`. -. Click the {ProductName} Operator. +. Click the {SMProductName} Operator. . Click the *Istio Service Mesh Member Roll* tab. @@ -53,7 +53,7 @@ You can add a project to the `ServiceMeshMemberRoll` from the command line. .Prerequisites -* An installed, verified {ProductName} Operator. +* An installed, verified {SMProductName} Operator. * List of projects to add to the service mesh. * Access to the OpenShift CLI (`oc`). diff --git a/modules/ossm-member-roll-modify.adoc b/modules/ossm-member-roll-modify.adoc index 7bd9966445d8..bc23bb7a4c24 100644 --- a/modules/ossm-member-roll-modify.adoc +++ b/modules/ossm-member-roll-modify.adoc @@ -7,7 +7,7 @@ [id="ossm-member-roll-modify_{context}"] = Adding or removing projects from the service mesh -You can add or remove projects from an existing {ProductShortName} `ServiceMeshMemberRoll` resource using the web console. +You can add or remove projects from an existing {SMProductShortName} `ServiceMeshMemberRoll` resource using the web console. * You can add any number of projects, but a project can only belong to *one* `ServiceMeshMemberRoll` resource. @@ -17,7 +17,7 @@ You can add or remove projects from an existing {ProductShortName} `ServiceMeshM == Adding or removing projects from the member roll using the web console .Prerequisites -* An installed, verified {ProductName} Operator. +* An installed, verified {SMProductName} Operator. * An existing `ServiceMeshMemberRoll` resource. * Name of the project with the `ServiceMeshMemberRoll` resource. * Names of the projects you want to add or remove from the mesh. @@ -30,7 +30,7 @@ You can add or remove projects from an existing {ProductShortName} `ServiceMeshM . Click the *Project* menu and choose the project where your `ServiceMeshControlPlane` resource is deployed from the list, for example `istio-system`. -. Click the {ProductName} Operator. +. Click the {SMProductName} Operator. . Click the *Istio Service Mesh Member Roll* tab. @@ -47,11 +47,11 @@ You can add or remove projects from an existing {ProductShortName} `ServiceMeshM [id="ossm-member-roll-modify-cli_{context}"] == Adding or removing projects from the member roll using the CLI -You can modify an existing {ProductShortName} member roll using the command line. +You can modify an existing {SMProductShortName} member roll using the command line. .Prerequisites -* An installed, verified {ProductName} Operator. +* An installed, verified {SMProductName} Operator. * An existing `ServiceMeshMemberRoll` resource. * Name of the project with the `ServiceMeshMemberRoll` resource. * Names of the projects you want to add or remove from the mesh. diff --git a/modules/ossm-members.adoc b/modules/ossm-members.adoc index 2b5af76a93c2..41f303cd5836 100644 --- a/modules/ossm-members.adoc +++ b/modules/ossm-members.adoc @@ -4,9 +4,9 @@ // * service_mesh/v2x/installing-ossm.adoc [id="ossm-members_{context}"] -= Creating the {ProductName} members += Creating the {SMProductName} members -`ServiceMeshMember` resources provide a way for {ProductName} administrators to delegate permissions to add projects to a service mesh, even when the respective users don't have direct access to the service mesh project or member roll. While project administrators are automatically given permission to create the `ServiceMeshMember` resource in their project, they cannot point it to any `ServiceMeshControlPlane` until the service mesh administrator explicitly grants access to the service mesh. Administrators can grant users permissions to access the mesh by granting them the `mesh-user` user role. In this example, `istio-system` is the name of the control plane project. +`ServiceMeshMember` resources provide a way for {SMProductName} administrators to delegate permissions to add projects to a service mesh, even when the respective users don't have direct access to the service mesh project or member roll. While project administrators are automatically given permission to create the `ServiceMeshMember` resource in their project, they cannot point it to any `ServiceMeshControlPlane` until the service mesh administrator explicitly grants access to the service mesh. Administrators can grant users permissions to access the mesh by granting them the `mesh-user` user role. In this example, `istio-system` is the name of the control plane project. [source,terminal] ---- diff --git a/modules/ossm-migrating-to-20.adoc b/modules/ossm-migrating-to-20.adoc index a763017e82a3..b68280dd04eb 100644 --- a/modules/ossm-migrating-to-20.adoc +++ b/modules/ossm-migrating-to-20.adoc @@ -3,19 +3,19 @@ :_content-type: PROCEDURE [id="ossm-migrating-to-20_{context}"] -= Migrating {ProductName} from version 1.1 to version 2.0 += Migrating {SMProductName} from version 1.1 to version 2.0 -Upgrading from version 1.1 to 2.0 requires manual steps that migrate your workloads and application to a new instance of {ProductName} running the new version. +Upgrading from version 1.1 to 2.0 requires manual steps that migrate your workloads and application to a new instance of {SMProductName} running the new version. .Prerequisites -* You must upgrade to {product-title} 4.7. before you upgrade to {ProductName} 2.0. -* You must have {ProductName} version 2.0 operator. If you selected the *automatic* upgrade path, the operator automatically downloads the latest information. However, there are steps you must take to use the features in {ProductName} version 2.0. +* You must upgrade to {product-title} 4.7. before you upgrade to {SMProductName} 2.0. +* You must have {SMProductName} version 2.0 operator. If you selected the *automatic* upgrade path, the operator automatically downloads the latest information. However, there are steps you must take to use the features in {SMProductName} version 2.0. [id="ossm-migrating_{context}"] -== Upgrading {ProductName} +== Upgrading {SMProductName} -To upgrade {ProductName}, you must create an instance of {ProductName} `ServiceMeshControlPlane` v2 resource in a new namespace. Then, once it's configured, move your microservice applications and workloads from your old mesh to the new service mesh. +To upgrade {SMProductName}, you must create an instance of {SMProductName} `ServiceMeshControlPlane` v2 resource in a new namespace. Then, once it's configured, move your microservice applications and workloads from your old mesh to the new service mesh. .Procedure @@ -104,7 +104,7 @@ Alternatively, you can use the console to create the control plane. In the {prod [id="ossm-migrating-smcp_{context}"] == Configuring the 2.0 ServiceMeshControlPlane -The `ServiceMeshControlPlane` resource has been changed for {ProductName} version 2.0. After you created a v2 version of the `ServiceMeshControlPlane` resource, modify it to take advantage of the new features and to fit your deployment. Consider the following changes to the specification and behavior of {ProductName} 2.0 as you're modifying your `ServiceMeshControlPlane` resource. You can also refer to the {ProductName} 2.0 product documentation for new information to features you use. The v2 resource must be used for {ProductName} 2.0 installations. +The `ServiceMeshControlPlane` resource has been changed for {SMProductName} version 2.0. After you created a v2 version of the `ServiceMeshControlPlane` resource, modify it to take advantage of the new features and to fit your deployment. Consider the following changes to the specification and behavior of {SMProductName} 2.0 as you're modifying your `ServiceMeshControlPlane` resource. You can also refer to the {SMProductName} 2.0 product documentation for new information to features you use. The v2 resource must be used for {SMProductName} 2.0 installations. [id="ossm-migrating-differences-arch_{context}"] === Architecture changes @@ -113,7 +113,7 @@ The architectural units used by previous versions have been replaced by Istiod. Although Mixer is no longer supported as a control plane component, Mixer policy and telemetry plugins are now supported through WASM extensions in Istiod. Mixer can be enabled for policy and telemetry if you need to integrate legacy Mixer plugins. -Secret Discovery Service (SDS) is used to distribute certificates and keys to sidecars directly from Istiod. In {ProductName} version 1.1, secrets were generated by Citadel, which were used by the proxies to retrieve their client certificates and keys. +Secret Discovery Service (SDS) is used to distribute certificates and keys to sidecars directly from Istiod. In {SMProductName} version 1.1, secrets were generated by Citadel, which were used by the proxies to retrieve their client certificates and keys. [id="ossm-migrating-differences-annotation_{context}"] === Annotation changes @@ -129,7 +129,7 @@ The following annotations are no longer supported in v2.0. If you are using one [id="ossm-migrating-differences-behavior_{context}"] === Behavioral changes -Some features in {ProductName} 2.0 work differently than they did in previous versions. +Some features in {SMProductName} 2.0 work differently than they did in previous versions. * The readiness port on gateways has moved from `15020` to `15021`. * The target host visibility includes VirtualService, as well as ServiceEntry resources. It includes any restrictions applied through Sidecar resources. @@ -157,7 +157,7 @@ Additional authentication methods specified in `spec.origins`, must be mapped in .ServiceMeshPolicy (maistra.io/v1) -ServiceMeshPolicy was configured automatically for the control plane through the `spec.istio.global.mtls.enabled` in the v1 resource or `spec.security.dataPlane.mtls` in the v2 resource setting. For v2 control planes, a functionally equivalent PeerAuthentication resource is created during installation. This feature is deprecated in {ProductName} version 2.0 +ServiceMeshPolicy was configured automatically for the control plane through the `spec.istio.global.mtls.enabled` in the v1 resource or `spec.security.dataPlane.mtls` in the v2 resource setting. For v2 control planes, a functionally equivalent PeerAuthentication resource is created during installation. This feature is deprecated in {SMProductName} version 2.0 .RbacConfig, ServiceRole, ServiceRoleBinding (rbac.istio.io/v1alpha1) @@ -201,7 +201,7 @@ spec: Legacy mixer plugins can also be migrated to WASM and integrated using the new ServiceMeshExtension (maistra.io/v1alpha1) custom resource. -Built-in WASM filters included in the upstream Istio distribution are not available in {ProductName} 2.0. +Built-in WASM filters included in the upstream Istio distribution are not available in {SMProductName} 2.0. [id="ossm-migrating-mtls_{context}"] === Mutual TLS changes @@ -214,7 +214,7 @@ For information about mTLS, see xref:../../service_mesh/v2x/ossm-security.html#o ==== Other mTLS Examples -To disable mTLS For productpage service in the bookinfo sample application, your Policy resource was configured the following way for {ProductName} v1.1. +To disable mTLS For productpage service in the bookinfo sample application, your Policy resource was configured the following way for {SMProductName} v1.1. .Example Policy resource [source,yaml] @@ -229,7 +229,7 @@ spec: - name: productpage ---- -To disable mTLS For productpage service in the bookinfo sample application, use the following example to configure your PeerAuthentication resource for {ProductName} v2.0. +To disable mTLS For productpage service in the bookinfo sample application, use the following example to configure your PeerAuthentication resource for {SMProductName} v2.0. .Example PeerAuthentication resource [source,yaml] @@ -248,7 +248,7 @@ spec: app: productpage ---- -To enable mTLS With JWT authentication for the `productpage` service in the bookinfo sample application, your Policy resource was configured the following way for {ProductName} v1.1. +To enable mTLS With JWT authentication for the `productpage` service in the bookinfo sample application, your Policy resource was configured the following way for {SMProductName} v1.1. .Example Policy resource [source,yaml] @@ -279,7 +279,7 @@ spec: principalBinding: USE_ORIGIN ---- -To enable mTLS With JWT authentication for the productpage service in the bookinfo sample application, use the following example to configure your PeerAuthentication resource for {ProductName} v2.0. +To enable mTLS With JWT authentication for the productpage service in the bookinfo sample application, use the following example to configure your PeerAuthentication resource for {SMProductName} v2.0. .Example PeerAuthentication resource [source,yaml] diff --git a/modules/ossm-mixer-policy-1x.adoc b/modules/ossm-mixer-policy-1x.adoc index c7564335a64f..de871c3129bf 100644 --- a/modules/ossm-mixer-policy-1x.adoc +++ b/modules/ossm-mixer-policy-1x.adoc @@ -6,7 +6,7 @@ [id="ossm-mixer-policy-1x_{context}"] = Updating Mixer policy enforcement -In previous versions of {ProductName}, Mixer's policy enforcement was enabled by default. Mixer policy enforcement is now disabled by default. You must enable it before running policy tasks. +In previous versions of {SMProductName}, Mixer's policy enforcement was enabled by default. Mixer policy enforcement is now disabled by default. You must enable it before running policy tasks. .Prerequisites * Access to the OpenShift CLI (`oc`). @@ -24,7 +24,7 @@ NOTE: The examples use `` as the control plane namespace. Replace $ oc get cm -n istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks ---- -. If `disablePolicyChecks: true`, edit the {ProductShortName} ConfigMap: +. If `disablePolicyChecks: true`, edit the {SMProductShortName} ConfigMap: + [source,terminal] ---- diff --git a/modules/ossm-mixer-policy.adoc b/modules/ossm-mixer-policy.adoc index 0bf226241fe7..6f2ff034ad4c 100644 --- a/modules/ossm-mixer-policy.adoc +++ b/modules/ossm-mixer-policy.adoc @@ -5,7 +5,7 @@ [id="ossm-mixer-policy_{context}"] = Updating Mixer policy enforcement -In previous versions of {ProductName}, Mixer's policy enforcement was enabled by default. Mixer policy enforcement is now disabled by default. You must enable it before running policy tasks. +In previous versions of {SMProductName}, Mixer's policy enforcement was enabled by default. Mixer policy enforcement is now disabled by default. You must enable it before running policy tasks. .Prerequisites * Access to the OpenShift CLI (`oc`). @@ -26,7 +26,7 @@ The examples use `` as the control plane namespace. Replace this v $ oc get cm -n istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks ---- -. If `disablePolicyChecks: true`, edit the {ProductShortName} ConfigMap: +. If `disablePolicyChecks: true`, edit the {SMProductShortName} ConfigMap: + [source,terminal] ---- diff --git a/modules/ossm-multitenant.adoc b/modules/ossm-multitenant.adoc index 2df5383abca8..968e88f5c4fd 100644 --- a/modules/ossm-multitenant.adoc +++ b/modules/ossm-multitenant.adoc @@ -6,9 +6,9 @@ Module included in the following assemblies: [id="ossm-multitenant-install_{context}"] = Multitenant installations -Whereas upstream Istio takes a single tenant approach, {ProductName} supports multiple independent control planes within the cluster. {ProductName} uses a multitenant operator to manage the control plane lifecycle. +Whereas upstream Istio takes a single tenant approach, {SMProductName} supports multiple independent control planes within the cluster. {SMProductName} uses a multitenant operator to manage the control plane lifecycle. -{ProductName} installs a multitenant control plane by default. You specify the projects that can access the {ProductShortName}, and isolate the {ProductShortName} from other control plane instances. +{SMProductName} installs a multitenant control plane by default. You specify the projects that can access the {SMProductShortName}, and isolate the {SMProductShortName} from other control plane instances. [id="ossm-mt-vs-clusterwide_{context}"] == Multitenancy versus cluster-wide installations @@ -17,18 +17,18 @@ The main difference between a multitenant installation and a cluster-wide instal Every project in the `ServiceMeshMemberRoll` `members` list will have a `RoleBinding` for each service account associated with the control plane deployment and each control plane deployment will only watch those member projects. Each member project has a `maistra.io/member-of` label added to it, where the `member-of` value is the project containing the control plane installation. -{ProductName} configures each member project to ensure network access between itself, the control plane, and other member projects. The exact configuration differs depending on how {product-title} software-defined networking (SDN) is configured. See About OpenShift SDN for additional details. +{SMProductName} configures each member project to ensure network access between itself, the control plane, and other member projects. The exact configuration differs depending on how {product-title} software-defined networking (SDN) is configured. See About OpenShift SDN for additional details. If the {product-title} cluster is configured to use the SDN plug-in: -* *`NetworkPolicy`*: {ProductName} creates a `NetworkPolicy` resource in each member project allowing ingress to all pods from the other members and the control plane. If you remove a member from {ProductShortName}, this `NetworkPolicy` resource is deleted from the project. +* *`NetworkPolicy`*: {SMProductName} creates a `NetworkPolicy` resource in each member project allowing ingress to all pods from the other members and the control plane. If you remove a member from {SMProductShortName}, this `NetworkPolicy` resource is deleted from the project. + [NOTE] ==== This also restricts ingress to only member projects. If you require ingress from non-member projects, you need to create a `NetworkPolicy` to allow that traffic through. ==== -* *Multitenant*: {ProductName} joins the `NetNamespace` for each member project to the `NetNamespace` of the control plane project (the equivalent of running `oc adm pod-network join-projects --to control-plane-project member-project`). If you remove a member from the {ProductShortName}, its `NetNamespace` is isolated from the control plane (the equivalent of running `oc adm pod-network isolate-projects member-project`). +* *Multitenant*: {SMProductName} joins the `NetNamespace` for each member project to the `NetNamespace` of the control plane project (the equivalent of running `oc adm pod-network join-projects --to control-plane-project member-project`). If you remove a member from the {SMProductShortName}, its `NetNamespace` is isolated from the control plane (the equivalent of running `oc adm pod-network isolate-projects member-project`). * *Subnet*: No additional configuration is performed. diff --git a/modules/ossm-networkpolicy-overview.adoc b/modules/ossm-networkpolicy-overview.adoc index a29b3fd5dd37..93e42b5daf6a 100644 --- a/modules/ossm-networkpolicy-overview.adoc +++ b/modules/ossm-networkpolicy-overview.adoc @@ -6,6 +6,6 @@ This module included in the following assemblies: [id="ossm-understanding-networkpolicy_{context}"] = Understanding network policies -{ProductName} automatically creates and manages a number of `NetworkPolicies` resources in the control plane and application namespaces. This is to ensure that applications and the control plane can communicate with each other. +{SMProductName} automatically creates and manages a number of `NetworkPolicies` resources in the control plane and application namespaces. This is to ensure that applications and the control plane can communicate with each other. -For example, if you have configured your {product-title} cluster to use the SDN plug-in, {ProductName} creates a `NetworkPolicy` resource in each member project. This enables ingress to all pods in the mesh from the other mesh members and the control plane. This also restricts ingress to only member projects. If you require ingress from non-member projects, you need to create a `NetworkPolicy` to allow that traffic through. If you remove a namespace from {ProductShortName}, this `NetworkPolicy` resource is deleted from the project. +For example, if you have configured your {product-title} cluster to use the SDN plug-in, {SMProductName} creates a `NetworkPolicy` resource in each member project. This enables ingress to all pods in the mesh from the other mesh members and the control plane. This also restricts ingress to only member projects. If you require ingress from non-member projects, you need to create a `NetworkPolicy` to allow that traffic through. If you remove a namespace from {SMProductShortName}, this `NetworkPolicy` resource is deleted from the project. diff --git a/modules/ossm-observability-access.adoc b/modules/ossm-observability-access.adoc index 7981a1cc5e01..c61de8ff4296 100644 --- a/modules/ossm-observability-access.adoc +++ b/modules/ossm-observability-access.adoc @@ -7,9 +7,9 @@ [id="ossm-observability-access-console_{context}"] = Viewing service mesh data -The Kiali operator works with the telemetry data gathered in {ProductName} to provide graphs and real-time network diagrams of the applications, services, and workloads in your namespace. +The Kiali operator works with the telemetry data gathered in {SMProductName} to provide graphs and real-time network diagrams of the applications, services, and workloads in your namespace. -To access the Kiali console you must have {ProductName} installed and projects configured for the service mesh. +To access the Kiali console you must have {SMProductName} installed and projects configured for the service mesh. .Procedure diff --git a/modules/ossm-observability-addresses.adoc b/modules/ossm-observability-addresses.adoc index 9a4509f3aaaa..529fbc5e7272 100644 --- a/modules/ossm-observability-addresses.adoc +++ b/modules/ossm-observability-addresses.adoc @@ -7,12 +7,12 @@ Module included in the following assemblies: [id="ossm-observability-addresses_{context}"] = Discovering console addresses -{ProductName} provides the following consoles to view your service mesh data: +{SMProductName} provides the following consoles to view your service mesh data: -* *Kiali console* - Kiali is the management console for {ProductName}. +* *Kiali console* - Kiali is the management console for {SMProductName}. * *Jaeger console* - Jaeger is the management console for {DTProductName}. * *Grafana console* - 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. -* *Prometheus console* - {ProductName} uses Prometheus to store telemetry information from services. +* *Prometheus console* - {SMProductName} uses Prometheus to store telemetry information from services. When you install the Service Mesh control plane, it automatically generates routes for each of the installed components. Once you have the route address, you can access the Kiali, Jaeger, Prometheus, or Grafana console to view and manage your service mesh data. @@ -35,7 +35,7 @@ The *Location* column displays the linked address for each route. . Click *Log In With OpenShift*. .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] ---- @@ -49,7 +49,7 @@ $ oc login https://:6443 $ oc project istio-system ---- + -. To get the routes for the various {ProductName} consoles, run the folowing command: +. To get the routes for the various {SMProductName} consoles, run the folowing command: + [source,terminal] ---- diff --git a/modules/ossm-recommended-resources.adoc b/modules/ossm-recommended-resources.adoc index 9c4dcd511a6f..b735010185ec 100644 --- a/modules/ossm-recommended-resources.adoc +++ b/modules/ossm-recommended-resources.adoc @@ -17,7 +17,7 @@ The settings in the following example are based on 1,000 services and 1,000 requ . 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`, for example `basic`. +. Click the {SMProductName} Operator. In the *Istio Service Mesh Control Plane* column, click the name of your `ServiceMeshControlPlane`, for example `basic`. . Add the name of your standalone Jaeger instance to the `ServiceMeshControlPlane`. + diff --git a/modules/ossm-remove-cleanup-1x.adoc b/modules/ossm-remove-cleanup-1x.adoc index aba8ce212961..2db4fe27d580 100644 --- a/modules/ossm-remove-cleanup-1x.adoc +++ b/modules/ossm-remove-cleanup-1x.adoc @@ -7,7 +7,7 @@ [id="ossm-remove-cleanup-1x_{context}"] = Clean up Operator resources -Follow this procedure to manually remove resources left behind after removing the {ProductName} Operator using the {product-title} web console. +Follow this procedure to manually remove resources left behind after removing the {SMProductName} Operator using the {product-title} web console. .Prerequisites @@ -22,7 +22,7 @@ Follow this procedure to manually remove resources left behind after removing th + [NOTE] ==== -The Operators are installed in the `openshift-operators` namespace by default. If you installed the Operators in another namespace, replace `openshift-operators` with the name of the project where the {ProductName} Operator was installed. +The Operators are installed in the `openshift-operators` namespace by default. If you installed the Operators in another namespace, replace `openshift-operators` with the name of the project where the {SMProductName} Operator was installed. ==== + [source,terminal] diff --git a/modules/ossm-remove-cleanup.adoc b/modules/ossm-remove-cleanup.adoc index f016841489ad..1712570ca4dd 100644 --- a/modules/ossm-remove-cleanup.adoc +++ b/modules/ossm-remove-cleanup.adoc @@ -7,7 +7,7 @@ [id="ossm-remove-cleanup_{context}"] = Clean up Operator resources -You can manually remove resources left behind after removing the {ProductName} Operator using the {product-title} web console. +You can manually remove resources left behind after removing the {SMProductName} Operator using the {product-title} web console. .Prerequisites @@ -22,7 +22,7 @@ You can manually remove resources left behind after removing the {ProductName} O + [NOTE] ==== -The OpenShift Elasticsearch Operator is installed in `openshift-operators-redhat` by default. The other Operators are installed in the `openshift-operators` namespace by default. If you installed the Operators in another namespace, replace `openshift-operators` with the name of the project where the {ProductName} Operator was installed. +The OpenShift Elasticsearch Operator is installed in `openshift-operators-redhat` by default. The other Operators are installed in the `openshift-operators` namespace by default. If you installed the Operators in another namespace, replace `openshift-operators` with the name of the project where the {SMProductName} Operator was installed. ==== + [source,terminal] diff --git a/modules/ossm-remove-operators.adoc b/modules/ossm-remove-operators.adoc index b571c2e48e1c..d648cf4694ec 100644 --- a/modules/ossm-remove-operators.adoc +++ b/modules/ossm-remove-operators.adoc @@ -7,14 +7,14 @@ [id="ossm-operatorhub-remove-operators_{context}"] = Removing the installed Operators -You must remove the Operators to successfully remove {ProductName}. After you remove the {ProductName} Operator, you must remove the Kiali Operator, the {JaegerName} Operator, and the OpenShift Elasticsearch Operator. +You must remove the Operators to successfully remove {SMProductName}. After you remove the {SMProductName} Operator, you must remove the Kiali Operator, the {JaegerName} Operator, and the OpenShift Elasticsearch Operator. [id="ossm-remove-operator-servicemesh_{context}"] == Removing the Operators -Follow this procedure to remove the Operators that make up {ProductName}. Repeat the steps for each of the following Operators. +Follow this procedure to remove the Operators that make up {SMProductName}. Repeat the steps for each of the following Operators. -* {ProductName} +* {SMProductName} * Kiali * {JaegerName} * OpenShift Elasticsearch diff --git a/modules/ossm-rn-deprecated-features-1x.adoc b/modules/ossm-rn-deprecated-features-1x.adoc index 22fbeb4d64c9..7351e7d5f259 100644 --- a/modules/ossm-rn-deprecated-features-1x.adoc +++ b/modules/ossm-rn-deprecated-features-1x.adoc @@ -13,7 +13,7 @@ Some features available in previous releases have been deprecated or removed. Deprecated functionality is still included in {product-title} and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments. -== Deprecated features {ProductName} 1.1.5 +== Deprecated features {SMProductName} 1.1.5 The following custom resources were deprecated in release 1.1.5 and were removed in release 1.1.12 @@ -23,8 +23,8 @@ The following custom resources were deprecated in release 1.1.5 and were removed ** `ServiceRole` ** `ServiceRoleBinding` * `RbacConfig` - `RbacConfig` implements the Custom Resource Definition for controlling Istio RBAC behavior. -** `ClusterRbacConfig`(versions prior to {ProductName} 1.0) -** `ServiceMeshRbacConfig` ({ProductName} version 1.0 and later) +** `ClusterRbacConfig`(versions prior to {SMProductName} 1.0) +** `ServiceMeshRbacConfig` ({SMProductName} version 1.0 and later) * In Kiali, the `login` and `LDAP` strategies are deprecated. A future version will introduce authentication using OpenID providers. The following components are also deprecated in this release and will be replaced by the *Istiod* component in a future release. diff --git a/modules/ossm-rn-deprecated-features.adoc b/modules/ossm-rn-deprecated-features.adoc index 6d9da5de6699..08b410b33c57 100644 --- a/modules/ossm-rn-deprecated-features.adoc +++ b/modules/ossm-rn-deprecated-features.adoc @@ -15,7 +15,7 @@ Deprecated functionality is still included in {product-title} and continues to b Removed functionality no longer exists in the product. -== Removed features {ProductName} 2.1 +== Removed features {SMProductName} 2.1 In Service Mesh 2.1, the Mixer component is removed. Bug fixes and support is provided through the end of the Service Mesh 2.0 life cycle. @@ -23,11 +23,11 @@ Upgrading from a Service Mesh 2.0.x release to 2.1 will not proceed if Mixer plu With Mixer removed, custom metrics for telemetry must be obtained using Envoy filter. -== Deprecated features {ProductName} 2.0 +== Deprecated features {SMProductName} 2.0 The Mixer component was deprecated in release 2.0 and will be removed in release 2.1. While using Mixer for implementing extensions was still supported in release 2.0, extensions should have been migrated to the new link:https://istio.io/latest/blog/2020/wasm-announce/[WebAssembly] mechanism. -The following resource types are no longer supported in {ProductName} 2.0: +The following resource types are no longer supported in {SMProductName} 2.0: * `Policy` (authentication.istio.io/v1alpha1) is no longer supported. Depending on the specific configuration in your Policy resource, you may have to configure multiple resources to achieve the same effect. ** Use `RequestAuthentication` (security.istio.io/v1beta1) diff --git a/modules/ossm-rn-fixed-issues-1x.adoc b/modules/ossm-rn-fixed-issues-1x.adoc index 5f399fffad15..14dbd680a216 100644 --- a/modules/ossm-rn-fixed-issues-1x.adoc +++ b/modules/ossm-rn-fixed-issues-1x.adoc @@ -17,7 +17,7 @@ Provide the following info for each issue if possible: The following issues been resolved in the current release: [id="ossm-rn-fixed-issues-ossm_{context}"] -== {ProductShortName} fixed issues +== {SMProductShortName} fixed issues * link:https://issues.redhat.com/browse/MAISTRA-2371[MAISTRA-2371] Handle tombstones in listerInformer. The updated cache codebase was not handling tombstones when translating the events from the namespace caches to the aggregated cache, leading to a panic in the go routine. @@ -34,7 +34,7 @@ The following issues been resolved in the current release: * link:https://issues.redhat.com/browse/MAISTRA-1541[MAISTRA-1541] Panic in kubernetesenv when the controller is not set on owner reference. If a pod has an ownerReference which does not specify the controller, this will cause a panic within the `kubernetesenv cache.go` code. -* link:https://issues.redhat.com/browse/MAISTRA-1352[MAISTRA-1352] Cert-manager Custom Resource Definitions (CRD) from the control plane installation have been removed for this release and future releases. If you have already installed {ProductName}, the CRDs must be removed manually if cert-manager is not being used. +* link:https://issues.redhat.com/browse/MAISTRA-1352[MAISTRA-1352] Cert-manager Custom Resource Definitions (CRD) from the control plane installation have been removed for this release and future releases. If you have already installed {SMProductName}, the CRDs must be removed manually if cert-manager is not being used. * link:https://issues.jboss.org/browse/MAISTRA-1001[MAISTRA-1001] Closing HTTP/2 connections could lead to segmentation faults in `istio-proxy`. @@ -44,7 +44,7 @@ The following issues been resolved in the current release: * link:https://issues.jboss.org/browse/MAISTRA-833[MAISTRA-833] Pilot stopped delivering configuration after many namespace deletions and re-creations. -* link:https://issues.jboss.org/browse/MAISTRA-684[MAISTRA-684] The default Jaeger version in the `istio-operator` is 1.12.0, which does not match Jaeger version 1.13.1 that shipped in {ProductName} 0.12.TechPreview. +* link:https://issues.jboss.org/browse/MAISTRA-684[MAISTRA-684] The default Jaeger version in the `istio-operator` is 1.12.0, which does not match Jaeger version 1.13.1 that shipped in {SMProductName} 0.12.TechPreview. * link:https://issues.jboss.org/browse/MAISTRA-622[MAISTRA-622] In Maistra 0.12.0/TP12, permissive mode does not work. The user has the option to use Plain text mode or Mutual TLS mode, but not permissive. @@ -65,7 +65,7 @@ The following issues been resolved in the current release: * link:https://issues.jboss.org/browse/KIALI-3118[KIALI-3118] After changes to the ServiceMeshMemberRoll, for example adding or removing projects, the Kiali pod restarts and then displays errors on the Graph page while the Kiali pod is restarting. -* link:https://issues.jboss.org/browse/KIALI-3096[KIALI-3096] Runtime metrics fail in {ProductShortName}. There is an OAuth filter between the {ProductShortname} and Prometheus, requiring a bearer token to be passed to Prometheus before access is granted. Kiali has been updated to use this token when communicating to the Prometheus server, but the application metrics are currently failing with 403 errors. +* link:https://issues.jboss.org/browse/KIALI-3096[KIALI-3096] Runtime metrics fail in {SMProductShortName}. There is an OAuth filter between the {SMProductShortName} and Prometheus, requiring a bearer token to be passed to Prometheus before access is granted. Kiali has been updated to use this token when communicating to the Prometheus server, but the application metrics are currently failing with 403 errors. * link:https://issues.jboss.org/browse/KIALI-3070[KIALI-3070] This bug only affects custom dashboards, not the default dashboards. When you select labels in metrics settings and refresh the page, your selections are retained in the menu but your selections are not displayed on the charts. diff --git a/modules/ossm-rn-fixed-issues.adoc b/modules/ossm-rn-fixed-issues.adoc index 6cb586668926..8a4001c3dacf 100644 --- a/modules/ossm-rn-fixed-issues.adoc +++ b/modules/ossm-rn-fixed-issues.adoc @@ -17,7 +17,7 @@ Provide the following info for each issue if possible: The following issues been resolved in the current release: [id="ossm-rn-fixed-issues-ossm_{context}"] -== {ProductShortName} fixed issues +== {SMProductShortName} fixed issues * link:https://issues.redhat.com/browse/OSSM-797[OSSM-797] Kiali Operator pod generates `CreateContainerConfigError` while installing or updating the operator. @@ -38,15 +38,15 @@ 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.jboss.org/browse/MAISTRA-2687[MAISTRA-2687] {ProductName} 2.1 federation gateway does not send the full certificate chain when using external certificates. The {ProductShortName} federation egress gateway only sends the client certificate. Because the federation ingress gateway only knows about the root certificate, it cannot verify the client certificate unless you add the root certificate to the federation import `ConfigMap`. +* link:https://issues.jboss.org/browse/MAISTRA-2687[MAISTRA-2687] {SMProductName} 2.1 federation gateway does not send the full certificate chain when using external certificates. The {SMProductShortName} federation egress gateway only sends the client certificate. Because the federation ingress gateway only knows about the root certificate, it cannot verify the client certificate unless you add the root certificate to the federation import `ConfigMap`. -* link:https://issues.redhat.com/browse/MAISTRA-2635[MAISTRA-2635] Replace deprecated Kubernetes API. To remain compatible with {product-title} 4.8, the `apiextensions.k8s.io/v1beta1` API was deprecated as of {ProductName} 2.0.8. +* link:https://issues.redhat.com/browse/MAISTRA-2635[MAISTRA-2635] Replace deprecated Kubernetes API. To remain compatible with {product-title} 4.8, the `apiextensions.k8s.io/v1beta1` API was deprecated as of {SMProductName} 2.0.8. -* link:https://issues.redhat.com/browse/MAISTRA-2631[MAISTRA-2631] The WASM feature is not working because podman is failing due to nsenter binary not being present. {ProductName} generates the following error message: `Error: error configuring CNI network plugin exec: "nsenter": executable file not found in $PATH`. The container image now contains nsenter and WASM works as expected. +* link:https://issues.redhat.com/browse/MAISTRA-2631[MAISTRA-2631] The WASM feature is not working because podman is failing due to nsenter binary not being present. {SMProductName} generates the following error message: `Error: error configuring CNI network plugin exec: "nsenter": executable file not found in $PATH`. The container image now contains nsenter and WASM works as expected. -* 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 {ProductShortName} 2.0.7 release. +* 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.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 {Productname} 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: +* 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: ** Galley ** Grafana @@ -56,13 +56,13 @@ Namespace starting with `kube` is hidden from Kiali. ** Prometheus ** Sidecar injector -* link:https://issues.redhat.com/browse/MAISTRA-2378[MAISTRA-2378] When the cluster is configured to use OpenShift SDN with `ovs-multitenant` and the mesh contains a large number of namespaces (200+), the {product-title} networking plugin is unable to configure the namespaces quickly. {ProductShortName} times out causing namespaces to be continuously dropped from the service mesh and then reenlisted. +* link:https://issues.redhat.com/browse/MAISTRA-2378[MAISTRA-2378] When the cluster is configured to use OpenShift SDN with `ovs-multitenant` and the mesh contains a large number of namespaces (200+), the {product-title} networking plugin is unable to configure the namespaces quickly. {SMProductShortName} times out causing namespaces to be continuously dropped from the service mesh and then reenlisted. * link:https://issues.redhat.com/browse/MAISTRA-2370[MAISTRA-2370] Handle tombstones in listerInformer. The updated cache codebase was not handling tombstones when translating the events from the namespace caches to the aggregated cache, leading to a panic in the go routine. * link:https://issues.redhat.com/browse/MAISTRA-2117[MAISTRA-2117] Add optional `ConfigMap` mount to operator. The CSV now contains an optional `ConfigMap` volume mount, which mounts the `smcp-templates` `ConfigMap` if it exists. If the `smcp-templates` `ConfigMap` does not exist, the mounted directory is empty. When you create the `ConfigMap`, the directory is populated with the entries from the `ConfigMap` and can be referenced in `SMCP.spec.profiles`. No restart of the Service Mesh operator is required. + -Customers using the 2.0 operator with a modified CSV to mount the smcp-templates ConfigMap can upgrade to {ProductName} 2.1. After upgrading, you can continue using an existing ConfigMap, and the profiles it contains, without editing the CSV. Customers that previously used ConfigMap with a different name will either have to rename the ConfigMap or update the CSV after upgrading. +Customers using the 2.0 operator with a modified CSV to mount the smcp-templates ConfigMap can upgrade to {SMProductName} 2.1. After upgrading, you can continue using an existing ConfigMap, and the profiles it contains, without editing the CSV. Customers that previously used ConfigMap with a different name will either have to rename the ConfigMap or update the CSV after upgrading. * link:https://issues.redhat.com/browse/MAISTRA-2010[MAISTRA-2010] AuthorizationPolicy does not support `request.regex.headers` field. The `validatingwebhook` rejects any AuthorizationPolicy with the field, and even if you disable that, Pilot tries to validate it using the same code, and it does not work. @@ -81,7 +81,7 @@ This also causes the READY and STATUS columns to be empty when you run `oc get s * link:https://issues.redhat.com/browse/MAISTRA-1502[Maistra-1502] As a result of CVEs fixes in version 1.0.10, the Istio dashboards are not available from the *Home Dashboard* menu in Grafana. The Istio dashboards still exist. To access them, click the *Dashboard* menu in the navigation panel and select the *Manage* tab. -* link:https://issues.redhat.com/browse/MAISTRA-1399[MAISTRA-1399] {ProductName} no longer prevents you from installing unsupported CNI protocols. The supported network configurations has not changed. +* link:https://issues.redhat.com/browse/MAISTRA-1399[MAISTRA-1399] {SMProductName} no longer prevents you from installing unsupported CNI protocols. The supported network configurations has not changed. * link:https://issues.jboss.org/browse/MAISTRA-1089[MAISTRA-1089] _Migration to 2.0_ Gateways created in a non-control plane namespace are automatically deleted. After removing the gateway definition from the SMCP spec, you need to manually delete these resources. diff --git a/modules/ossm-rn-known-issues-1x.adoc b/modules/ossm-rn-known-issues-1x.adoc index 0831d52ffb0f..fc58c1608e36 100644 --- a/modules/ossm-rn-known-issues-1x.adoc +++ b/modules/ossm-rn-known-issues-1x.adoc @@ -13,22 +13,22 @@ Module included in the following assemblies: *Result* - If the workaround does not completely address the problem. //// -These limitations exist in {ProductName}: +These limitations exist in {SMProductName}: -* link:https://github.com/istio/old_issues_repo/issues/115[{ProductName} does not support IPv6], as it is not supported by the upstream Istio project, nor fully supported by {product-title}. +* link:https://github.com/istio/old_issues_repo/issues/115[{SMProductName} does not support IPv6], as it is not supported by the upstream Istio project, nor fully supported by {product-title}. * Graph layout - The layout for the Kiali graph can render differently, depending on your application architecture and the data to display (number of graph nodes and their interactions). Because it is difficult if not impossible to create a single layout that renders nicely for every situation, Kiali offers a choice of several different layouts. To choose a different layout, you can choose a different *Layout Schema* from the *Graph Settings* menu. * The first time you access related services such as Jaeger and Grafana, from the Kiali console, you must accept the certificate and re-authenticate using your {product-title} login credentials. This happens due to an issue with how the framework displays embedded pages in the console. [id="ossm-rn-known-issues-ossm_{context}"] -== {ProductShortName} known issues +== {SMProductShortName} known issues -These are the known issues in {ProductName}: +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://github.com/istio/istio/issues/14743[Istio-14743] Due to limitations in the version of Istio that this release of {ProductName} is based on, there are several applications that are currently incompatible with {ProductShortName}. See the linked community issue for details. +* 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. * link:https://issues.jboss.org/browse/MAISTRA-858[MAISTRA-858] The following Envoy log messages describing link:https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated[deprecated options and configurations associated with Istio 1.1.x] are expected: + diff --git a/modules/ossm-rn-known-issues.adoc b/modules/ossm-rn-known-issues.adoc index 2ad74762db4c..6b46ea2600b1 100644 --- a/modules/ossm-rn-known-issues.adoc +++ b/modules/ossm-rn-known-issues.adoc @@ -13,9 +13,9 @@ Module included in the following assemblies: *Result* - If the workaround does not completely address the problem. //// -These limitations exist in {ProductName}: +These limitations exist in {SMProductName}: -* {ProductName} does not yet support link:https://issues.redhat.com/browse/MAISTRA-1314[IPv6], as it is not yet fully supported by the upstream Istio project. +* {SMProductName} does not yet support link:https://issues.redhat.com/browse/MAISTRA-1314[IPv6], as it is not yet fully supported by the upstream Istio project. * Graph layout - The layout for the Kiali graph can render differently, depending on your application architecture and the data to display (number of graph nodes and their interactions). Because it is difficult if not impossible to create a single layout that renders nicely for every situation, Kiali offers a choice of several different layouts. To choose a different layout, you can choose a different *Layout Schema* from the *Graph Settings* menu. @@ -26,11 +26,11 @@ These limitations exist in {ProductName}: * WebAssembly is unsupported on IBM Z. [id="ossm-rn-known-issues-ossm_{context}"] -== {ProductShortName} known issues +== {SMProductShortName} known issues -These are the known issues in {ProductName}: +These are the known issues in {SMProductName}: -* link:https://github.com/istio/istio/issues/14743[Istio-14743] Due to limitations in the version of Istio that this release of {ProductName} is based on, there are several applications that are currently incompatible with {ProductShortName}. See the linked community issue for details. +* 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. * 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. + @@ -60,7 +60,7 @@ api: + Now, the Operator ignores resources that don't also include the `app.kubernetes.io/managed-by=maistra-istio-operator` label. If you create your own resources, you should not add the `app.kubernetes.io/managed-by=maistra-istio-operator` label to them. -* link:https://issues.redhat.com/browse/MAISTRA-2692[MAISTRA-2692] With Mixer removed, custom metrics that have been defined in {ProductShortName} 2.0.x cannot be used in 2.1. Custom metrics can be configured using `EnvoyFilter`. Red Hat is unable to support `EnvoyFilter` configuration except where explicitly documented. This is due to tight coupling with the underlying Envoy APIs, meaning that backward compatibility cannot be maintained. +* link:https://issues.redhat.com/browse/MAISTRA-2692[MAISTRA-2692] With Mixer removed, custom metrics that have been defined in {SMProductShortName} 2.0.x cannot be used in 2.1. Custom metrics can be configured using `EnvoyFilter`. Red Hat is unable to support `EnvoyFilter` configuration except where explicitly documented. This is due to tight coupling with the underlying Envoy APIs, meaning that backward compatibility cannot be maintained. * link:https://issues.redhat.com/browse/MAISTRA-2648[MAISTRA-2648] `ServiceMeshExtensions` are currently not compatible with meshes deployed on IBM Z Systems. @@ -83,7 +83,7 @@ spec: + * 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.redhat.com/browse/MAISTRA-1314[MAISTRA-1314] {ProductName} does not yet support IPv6. +* link:https://issues.redhat.com/browse/MAISTRA-1314[MAISTRA-1314] {SMProductName} does not yet support IPv6. * link:https://issues.jboss.org/browse/MAISTRA-806[MAISTRA-806] Evicted Istio Operator Pod causes mesh and CNI not to deploy. + diff --git a/modules/ossm-rn-new-features-1x.adoc b/modules/ossm-rn-new-features-1x.adoc index 7fcc969a5530..24d10f0e4735 100644 --- a/modules/ossm-rn-new-features-1x.adoc +++ b/modules/ossm-rn-new-features-1x.adoc @@ -12,14 +12,14 @@ Module included in the following assemblies: *Reason* – If known, include why has the enhancement been implemented (use case, performance, technology, etc.). For example, showcases integration of X with Y, demonstrates Z API feature, includes latest framework bug fixes. There may not have been a 'problem' previously, but system behavior may have changed. *Result* – If changed, describe the current user experience //// -{ProductName} provides a number of key capabilities uniformly across a network of services: +{SMProductName} provides a number of key capabilities uniformly across a network of services: * *Traffic Management* - Control the flow of traffic and API calls between services, make calls more reliable, and make the network more robust in the face of adverse conditions. * *Service Identity and Security* - Provide services in the mesh with a verifiable identity and provide the ability to protect service traffic as it flows over networks of varying degrees of trustworthiness. * *Policy Enforcement* - Apply organizational policy to the interaction between services, ensure access policies are enforced and resources are fairly distributed among consumers. Policy changes are made by configuring the mesh, not by changing application code. * *Telemetry* - Gain understanding of the dependencies between services and the nature and flow of traffic between them, providing the ability to quickly identify issues. -== Component versions included in {ProductName} version {ProductVersion} +== Component versions included in {SMProductName} version {SMProductVersion} |=== |Component |Version @@ -38,13 +38,13 @@ Module included in the following assemblies: |=== -== New features {ProductName} 1.1.17.1 +== New features {SMProductName} 1.1.17.1 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs). +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs). -=== Change in how {ProductName} handles URI fragments +=== Change in how {SMProductName} handles URI fragments -{ProductName} contains a remotely exploitable vulnerability, link:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39156[CVE-2021-39156], where an HTTP request with a fragment (a section in the end of a URI that begins with a # character) in the URI path could bypass the Istio URI path-based authorization policies. For instance, an Istio authorization policy denies requests sent to the URI path `/user/profile`. In the vulnerable versions, a request with URI path `/user/profile#section1` bypasses the deny policy and routes to the backend (with the normalized URI `path /user/profile%23section1`), possibly leading to a security incident. +{SMProductName} contains a remotely exploitable vulnerability, link:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39156[CVE-2021-39156], where an HTTP request with a fragment (a section in the end of a URI that begins with a # character) in the URI path could bypass the Istio URI path-based authorization policies. For instance, an Istio authorization policy denies requests sent to the URI path `/user/profile`. In the vulnerable versions, a request with URI path `/user/profile#section1` bypasses the deny policy and routes to the backend (with the normalized URI `path /user/profile%23section1`), possibly leading to a security incident. You are impacted by this vulnerability if you use authorization policies with DENY actions and `operation.paths`, or ALLOW actions and `operation.notPaths`. @@ -93,21 +93,21 @@ spec: hosts: ["httpbin.example.com:*"] ---- -== New features {ProductName} 1.1.17 +== New features {SMProductName} 1.1.17 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 1.1.16 +== New features {SMProductName} 1.1.16 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 1.1.15 +== New features {SMProductName} 1.1.15 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 1.1.14 +== New features {SMProductName} 1.1.14 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. [IMPORTANT] ==== @@ -133,7 +133,7 @@ Your cluster is NOT impacted by this vulnerability if: [NOTE] ==== -The {ProductName} configuration location for path normalization is different from the Istio configuration. +The {SMProductName} configuration location for path normalization is different from the Istio configuration. ==== === Updating the path normalization configuration @@ -213,7 +213,7 @@ The normalized URL paths, or the original URL paths if `NONE` is selected, will === Configuring your SMCP for path normalization -To configure path normalization for {ProductName}, specify the following in your `ServiceMeshControlPlane`. Use the configuration examples to help determine the settings for your system. +To configure path normalization for {SMProductName}, specify the following in your `ServiceMeshControlPlane`. Use the configuration examples to help determine the settings for your system. .SMCP v1 pathNormalization [source,yaml] @@ -224,47 +224,47 @@ spec: ---- -== New features {ProductName} 1.1.13 +== New features {SMProductName} 1.1.13 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 1.1.12 +== New features {SMProductName} 1.1.12 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 1.1.11 +== New features {SMProductName} 1.1.11 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 1.1.10 +== New features {SMProductName} 1.1.10 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 1.1.9 +== New features {SMProductName} 1.1.9 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 1.1.8 +== New features {SMProductName} 1.1.8 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 1.1.7 +== New features {SMProductName} 1.1.7 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 1.1.6 +== New features {SMProductName} 1.1.6 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 1.1.5 +== New features {SMProductName} 1.1.5 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. This release also added support for configuring cipher suites. -== New features {ProductName} 1.1.4 +== New features {SMProductName} 1.1.4 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. [NOTE] ==== @@ -278,7 +278,7 @@ The fix for link:https://bugzilla.redhat.com/show_bug.cgi?id=1844254[CVE-2020-86 [IMPORTANT] ==== -These manual steps are required to mitigate this CVE whether you are using the 1.1 version or the 1.0 version of {ProductName}. +These manual steps are required to mitigate this CVE whether you are using the 1.1 version or the 1.0 version of {SMProductName}. ==== This new configuration option is called `overload.global_downstream_max_connections`, and it is configurable as a proxy `runtime` setting. Perform the following steps to configure limits at the Ingress Gateway. @@ -443,34 +443,34 @@ $ oc get pods -n jaeger-system -w -== New features {ProductName} 1.1.3 +== New features {SMProductName} 1.1.3 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 1.1.2 +== New features {SMProductName} 1.1.2 -This release of {ProductName} addresses a security vulnerability. +This release of {SMProductName} addresses a security vulnerability. -== New features {ProductName} 1.1.1 +== New features {SMProductName} 1.1.1 -This release of {ProductName} adds support for a disconnected installation. +This release of {SMProductName} adds support for a disconnected installation. -== New features {ProductName} 1.1.0 +== New features {SMProductName} 1.1.0 -This release of {ProductName} adds support for Istio 1.4.6 and Jaeger 1.17.1. +This release of {SMProductName} adds support for Istio 1.4.6 and Jaeger 1.17.1. [id="ossm-manual-updates-1.0-1.1_{context}"] === Manual updates from 1.0 to 1.1 -If you are updating from {ProductName} 1.0 to 1.1, you must update the `ServiceMeshControlPlane` resource to update the control plane components to the new version. +If you are updating from {SMProductName} 1.0 to 1.1, you must update the `ServiceMeshControlPlane` resource to update the control plane components to the new version. -. In the web console, click the {ProductName} Operator. +. In the web console, click the {SMProductName} Operator. . Click the *Project* menu and choose the project where your `ServiceMeshControlPlane` is deployed from the list, for example `istio-system`. . Click the name of your control plane, for example `basic-install`. -. Click YAML and add a version field to the `spec:` of your `ServiceMeshControlPlane` resource. For example, to update to {ProductName} 1.1.0, add `version: v1.1`. +. Click YAML and add a version field to the `spec:` of your `ServiceMeshControlPlane` resource. For example, to update to {SMProductName} 1.1.0, add `version: v1.1`. ---- spec: @@ -478,9 +478,9 @@ spec: ... ---- -The version field specifies the version of {ProductShortName} to install and defaults to the latest available version. +The version field specifies the version of {SMProductShortName} to install and defaults to the latest available version. [NOTE] ==== -Note that support for {ProductName} v1.0 ended in October, 2020. You must upgrade to either v1.1 or v2.0. +Note that support for {SMProductName} v1.0 ended in October, 2020. You must upgrade to either v1.1 or v2.0. ==== diff --git a/modules/ossm-rn-new-features.adoc b/modules/ossm-rn-new-features.adoc index c2afef95d591..41459a3fdcfb 100644 --- a/modules/ossm-rn-new-features.adoc +++ b/modules/ossm-rn-new-features.adoc @@ -12,14 +12,14 @@ Module included in the following assemblies: *Reason* – If known, include why has the enhancement been implemented (use case, performance, technology, etc.). For example, showcases integration of X with Y, demonstrates Z API feature, includes latest framework bug fixes. There may not have been a 'problem' previously, but system behavior may have changed. *Result* – If changed, describe the current user experience //// -{ProductName} provides a number of key capabilities uniformly across a network of services: +{SMProductName} provides a number of key capabilities uniformly across a network of services: * *Traffic Management* - Control the flow of traffic and API calls between services, make calls more reliable, and make the network more robust in the face of adverse conditions. * *Service Identity and Security* - Provide services in the mesh with a verifiable identity and provide the ability to protect service traffic as it flows over networks of varying degrees of trustworthiness. * *Policy Enforcement* - Apply organizational policy to the interaction between services, ensure access policies are enforced and resources are fairly distributed among consumers. Policy changes are made by configuring the mesh, not by changing application code. * *Telemetry* - Gain understanding of the dependencies between services and the nature and flow of traffic between them, providing the ability to quickly identify issues. -== Component versions included in {ProductName} version {ProductVersion} +== Component versions included in {SMProductName} version {SMProductVersion} |=== |Component |Version @@ -37,22 +37,22 @@ Module included in the following assemblies: |1.36.7 |=== -== New features {ProductName} 2.1.1 +== New features {SMProductName} 2.1.1 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. This release also adds the ability to disable the automatic creation of network policies. [id="ossm-config-disable-networkpolicy_{context}"] === Disabling network policies -{ProductName} automatically creates and manages a number of `NetworkPolicies` resources in the control plane and application namespaces. This is to ensure that applications and the control plane can communicate with each other. +{SMProductName} automatically creates and manages a number of `NetworkPolicies` resources in the control plane and application namespaces. This is to ensure that applications and the control plane can communicate with each other. If you want to disable the automatic creation and management of `NetworkPolicies` resources, for example to enforce company security policies, you can do so. You can edit the `ServiceMeshControlPlane` to set the `spec.security.manageNetworkPolicy` setting to `false` [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. ==== .Procedure @@ -61,7 +61,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. @@ -79,9 +79,9 @@ spec: + . Click *Save*. -== New features and enhancements {ProductName} 2.1 +== New features and enhancements {SMProductName} 2.1 -This release of {ProductName} adds support for Istio 1.9.8, Envoy Proxy 1.17.1, Jaeger 1.24.1, and Kiali 1.36.5 on {product-title} 4.6 EUS, 4.7, 4.8, and 4.9. +This release of {SMProductName} adds support for Istio 1.9.8, Envoy Proxy 1.17.1, Jaeger 1.24.1, and Kiali 1.36.5 on {product-title} 4.6 EUS, 4.7, 4.8, and 4.9. In addition, this release has the following new features and enhancements: @@ -99,7 +99,7 @@ Service Mesh Federation is not supported between clusters on Red Hat OpenShift S === OVN-Kubernetes Container Network Interface (CNI) generally available -The OVN-Kubernetes Container Network Interface (CNI) was previously introduced as a Technology Preview feature in {ProductName} 2.0.1 and is now generally available in {ProductName} 2.1 and 2.0.x for use on {product-title} 4.7.32, {product-title} 4.8.12, and {product-title} 4.9. +The OVN-Kubernetes Container Network Interface (CNI) was previously introduced as a Technology Preview feature in {SMProductName} 2.0.1 and is now generally available in {SMProductName} 2.1 and 2.0.x for use on {product-title} 4.7.32, {product-title} 4.8.12, and {product-title} 4.9. === Service Mesh WebAssembly (WASM) Extensions @@ -115,7 +115,7 @@ With Mixer now officially removed, OpenShift Service Mesh 2.1 does not support t === Istio 1.9 Support -{ProductShortName} 2.1 is based on Istio 1.9, which brings in a large number of new features and product enhancements. While the majority of Istio 1.9 features are supported, the following exceptions should be noted: +{SMProductShortName} 2.1 is based on Istio 1.9, which brings in a large number of new features and product enhancements. While the majority of Istio 1.9 features are supported, the following exceptions should be noted: * Virtual Machine integration is not yet supported * Kubernetes Gateway API is not yet supported @@ -126,14 +126,14 @@ With Mixer now officially removed, OpenShift Service Mesh 2.1 does not support t === Improved Service Mesh operator performance -The amount of time {ProductName} uses to prune old resources at the end of every `ServiceMeshControlPlane` reconciliation has been reduced. This results in faster `ServiceMeshControlPlane` deployments, and allows changes applied to existing SMCPs to take effect more quickly. +The amount of time {SMProductName} uses to prune old resources at the end of every `ServiceMeshControlPlane` reconciliation has been reduced. This results in faster `ServiceMeshControlPlane` deployments, and allows changes applied to existing SMCPs to take effect more quickly. === Kiali updates Kiali 1.36 includes the following features and enhancements: -* {ProductShortName} troubleshooting functionality +* {SMProductShortName} troubleshooting functionality ** Control plane and gateway monitoring ** Proxy sync statuses ** Envoy configuration views @@ -141,17 +141,17 @@ Kiali 1.36 includes the following features and enhancements: * Namespace and cluster boxing to support federated service mesh views * New validations, wizards, and distributed tracing enhancements -== New features {ProductName} 2.0.8 +== New features {SMProductName} 2.0.8 -This release of {ProductName} addresses bug fixes. +This release of {SMProductName} addresses bug fixes. -== New features {ProductName} 2.0.7.1 +== New features {SMProductName} 2.0.7.1 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs). +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs). -=== Change in how {ProductName} handles URI fragments +=== Change in how {SMProductName} handles URI fragments -{ProductName} contains a remotely exploitable vulnerability, link:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39156[CVE-2021-39156], where an HTTP request with a fragment (a section in the end of a URI that begins with a # character) in the URI path could bypass the Istio URI path-based authorization policies. For instance, an Istio authorization policy denies requests sent to the URI path `/user/profile`. In the vulnerable versions, a request with URI path `/user/profile#section1` bypasses the deny policy and routes to the backend (with the normalized URI `path /user/profile%23section1`), possibly leading to a security incident. +{SMProductName} contains a remotely exploitable vulnerability, link:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39156[CVE-2021-39156], where an HTTP request with a fragment (a section in the end of a URI that begins with a # character) in the URI path could bypass the Istio URI path-based authorization policies. For instance, an Istio authorization policy denies requests sent to the URI path `/user/profile`. In the vulnerable versions, a request with URI path `/user/profile#section1` bypasses the deny policy and routes to the backend (with the normalized URI `path /user/profile%23section1`), possibly leading to a security incident. You are impacted by this vulnerability if you use authorization policies with DENY actions and `operation.paths`, or ALLOW actions and `operation.notPaths`. @@ -221,25 +221,25 @@ spec: hosts: ["httpbin.example.com:*"] ---- -== New features {ProductName} 2.0.7 +== New features {SMProductName} 2.0.7 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== {ProductName} on {product-dedicated} and Microsoft Azure Red Hat OpenShift +== {SMProductName} on {product-dedicated} and Microsoft Azure Red Hat OpenShift -{ProductName} is now supported through {product-dedicated} and Microsoft Azure Red Hat OpenShift. +{SMProductName} is now supported through {product-dedicated} and Microsoft Azure Red Hat OpenShift. -== New features {ProductName} 2.0.6 +== New features {SMProductName} 2.0.6 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 2.0.5 +== New features {SMProductName} 2.0.5 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 2.0.4 +== New features {SMProductName} 2.0.4 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. [IMPORTANT] ==== @@ -265,7 +265,7 @@ Your cluster is NOT impacted by this vulnerability if: [NOTE] ==== -The {ProductName} configuration location for path normalization is different from the Istio configuration. +The {SMProductName} configuration location for path normalization is different from the Istio configuration. ==== === Updating the path normalization configuration @@ -345,7 +345,7 @@ The normalized URL paths, or the original URL paths if `NONE` is selected, will === Configuring your SMCP for path normalization -To configure path normalization for {ProductName}, specify the following in your `ServiceMeshControlPlane`. Use the configuration examples to help determine the settings for your system. +To configure path normalization for {SMProductName}, specify the following in your `ServiceMeshControlPlane`. Use the configuration examples to help determine the settings for your system. .SMCP v2 pathNormalization [source,yaml] @@ -403,26 +403,26 @@ spec: ---- -== New features {ProductName} 2.0.3 +== New features {SMProductName} 2.0.3 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. In addition, this release has the following new features: * Added an option to the `must-gather` data collection tool that gathers information from a specified control plane namespace. For more information, see link:https://issues.redhat.com/browse/OSSM-351[OSSM-351]. * Improved performance for control planes with hundreds of namespaces -== New features {ProductName} 2.0.2 +== New features {SMProductName} 2.0.2 -This release of {ProductName} adds support for IBM Z and IBM Power Systems. It also addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} adds support for IBM Z and IBM Power Systems. It also addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 2.0.1 +== New features {SMProductName} 2.0.1 -This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. +This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes. -== New features {ProductName} 2.0 +== New features {SMProductName} 2.0 -This release of {ProductName} adds support for Istio 1.6.5, Jaeger 1.20.0, Kiali 1.24.2, and the 3scale Istio Adapter 2.0 and {product-title} 4.6. +This release of {SMProductName} adds support for Istio 1.6.5, Jaeger 1.20.0, Kiali 1.24.2, and the 3scale Istio Adapter 2.0 and {product-title} 4.6. In addition, this release has the following new features: diff --git a/modules/ossm-routing-bookinfo-applying.adoc b/modules/ossm-routing-bookinfo-applying.adoc index cfeb02e86566..7d70d18ced42 100644 --- a/modules/ossm-routing-bookinfo-applying.adoc +++ b/modules/ossm-routing-bookinfo-applying.adoc @@ -22,4 +22,4 @@ $ oc get virtualservices -o yaml + That command returns a resource of `kind: VirtualService` in YAML format. -You have configured {ProductShortName} to route to the `v1` version of the Bookinfo microservices including the `reviews` service version 1. +You have configured {SMProductShortName} to route to the `v1` version of the Bookinfo microservices including the `reviews` service version 1. diff --git a/modules/ossm-routing-bookinfo-example.adoc b/modules/ossm-routing-bookinfo-example.adoc index c0e5f6094e3b..1736f4c92b66 100644 --- a/modules/ossm-routing-bookinfo-example.adoc +++ b/modules/ossm-routing-bookinfo-example.adoc @@ -6,9 +6,9 @@ [id="ossm-routing-bookinfo_{context}"] = Routing tutorial -The {ProductShortName} Bookinfo sample application consists of four separate microservices, each with multiple versions. After installing the Bookinfo sample application, three different versions of the `reviews` microservice run concurrently. +The {SMProductShortName} Bookinfo sample application consists of four separate microservices, each with multiple versions. After installing the Bookinfo sample application, three different versions of the `reviews` microservice run concurrently. -When you access the Bookinfo app `/product` page in a browser and refresh several times, sometimes the book review output contains star ratings and other times it does not. Without an explicit default service version to route to, {ProductShortName} routes requests to all available versions one after the other. +When you access the Bookinfo app `/product` page in a browser and refresh several times, sometimes the book review output contains star ratings and other times it does not. Without an explicit default service version to route to, {SMProductShortName} routes requests to all available versions one after the other. This tutorial helps you apply rules that route all traffic to `v1` (version 1) of the microservices. Later, you can apply a rule to route traffic based on the value of an HTTP request header. diff --git a/modules/ossm-routing-bookinfo-route.adoc b/modules/ossm-routing-bookinfo-route.adoc index b5079b4073e4..891c7b7370af 100644 --- a/modules/ossm-routing-bookinfo-route.adoc +++ b/modules/ossm-routing-bookinfo-route.adoc @@ -4,7 +4,7 @@ Change the route configuration so that all traffic from a specific user is routed to a specific service version. In this case, all traffic from a user named `jason` will be routed to the service `reviews:v2`. -{ProductShortName} does not have any special, built-in understanding of user identity. This example is enabled by the fact that the `productpage` service adds a custom `end-user` header to all outbound HTTP requests to the reviews service. +{SMProductShortName} does not have any special, built-in understanding of user identity. This example is enabled by the fact that the `productpage` service adds a custom `end-user` header to all outbound HTTP requests to the reviews service. .Procedure diff --git a/modules/ossm-routing-bookinfo-test.adoc b/modules/ossm-routing-bookinfo-test.adoc index 963f29c49073..b19e466ab3d5 100644 --- a/modules/ossm-routing-bookinfo-test.adoc +++ b/modules/ossm-routing-bookinfo-test.adoc @@ -22,6 +22,6 @@ echo "http://$GATEWAY_URL/productpage" . Open the Bookinfo site in your browser. -The reviews part of the page displays with no rating stars, no matter how many times you refresh. This is because you configured {ProductShortName} to route all traffic for the reviews service to the version `reviews:v1` and this version of the service does not access the star ratings service. +The reviews part of the page displays with no rating stars, no matter how many times you refresh. This is because you configured {SMProductShortName} to route all traffic for the reviews service to the version `reviews:v1` and this version of the service does not access the star ratings service. Your service mesh now routes traffic to one version of a service. diff --git a/modules/ossm-routing-ingress.adoc b/modules/ossm-routing-ingress.adoc index b13cc4806c66..99aa8c2bb25c 100644 --- a/modules/ossm-routing-ingress.adoc +++ b/modules/ossm-routing-ingress.adoc @@ -7,7 +7,7 @@ [id="ossm-routing-ingress_{context}"] = Managing ingress traffic -In {ProductName}, the Ingress Gateway enables features such as monitoring, security, and route rules to apply to traffic that enters the cluster. Use a {ProductShortName} gateway to expose a service outside of the service mesh. +In {SMProductName}, the Ingress Gateway enables features such as monitoring, security, and route rules to apply to traffic that enters the cluster. Use a {SMProductShortName} gateway to expose a service outside of the service mesh. [id="ossm-routing-determine-ingress_{context}"] == Determining the ingress IP and ports diff --git a/modules/ossm-routing-sc.adoc b/modules/ossm-routing-sc.adoc index 982467ec8139..735b727d478d 100644 --- a/modules/ossm-routing-sc.adoc +++ b/modules/ossm-routing-sc.adoc @@ -2,7 +2,7 @@ [id="ossm-routing-sc_{context}"] = Sidecar -By default, {ProductName} configures every Envoy proxy to accept traffic on all the ports of its associated workload, and to reach every workload in the mesh when forwarding traffic. You can use a sidecar configuration to do the following: +By default, {SMProductName} configures every Envoy proxy to accept traffic on all the ports of its associated workload, and to reach every workload in the mesh when forwarding traffic. You can use a sidecar configuration to do the following: * Fine-tune the set of ports and protocols that an Envoy proxy accepts. * Limit the set of services that the Envoy proxy can reach. @@ -12,7 +12,7 @@ By default, {ProductName} configures every Envoy proxy to accept traffic on all To optimize performance of your service mesh, consider limiting Envoy proxy configurations. ==== -In the Bookinfo sample application, configure a Sidecar so all services can reach other services running in the same namespace and control plane. This Sidecar configuration is required for using {ProductName} policy and telemetry features. +In the Bookinfo sample application, configure a Sidecar so all services can reach other services running in the same namespace and control plane. This Sidecar configuration is required for using {SMProductName} policy and telemetry features. .Procedure diff --git a/modules/ossm-routing.adoc b/modules/ossm-routing.adoc index 396610efb291..3fcda20207c0 100644 --- a/modules/ossm-routing.adoc +++ b/modules/ossm-routing.adoc @@ -7,12 +7,12 @@ [id="ossm-routing_{context}"] = Routing and managing traffic -Configure your service mesh by adding your own traffic configuration to {ProductName} with a custom resource definitions in a YAML file. +Configure your service mesh by adding your own traffic configuration to {SMProductName} with a custom resource definitions in a YAML file. [id="ossm-routing-traffic-management-vs_{context}"] == Traffic management with virtual services -You can route requests dynamically to multiple versions of a microservice through {ProductName} with a virtual service. With virtual services, you can: +You can route requests dynamically to multiple versions of a microservice through {SMProductName} with a virtual service. With virtual services, you can: * Address multiple application services through a single virtual service. If your mesh uses Kubernetes, for example, you can configure a virtual service to handle all services in a specific namespace. A virtual service enables you to turn a monolithic application into a service comprised of distinct microservices with a seamless consumer experience. * Configure traffic rules in combination with gateways to control ingress and egress traffic. @@ -20,9 +20,9 @@ You can route requests dynamically to multiple versions of a microservice throug [id="ossm-routing-vs_{context}"] === Configuring virtual services -Requests are routed to services within a service mesh with virtual services. Each virtual service consists of a set of routing rules that are evaluated in order. {ProductName} matches each given request to the virtual service to a specific real destination within the mesh. +Requests are routed to services within a service mesh with virtual services. Each virtual service consists of a set of routing rules that are evaluated in order. {SMProductName} matches each given request to the virtual service to a specific real destination within the mesh. -Without virtual services, {ProductName} distributes traffic using round-robin load balancing between all service instances. With a virtual service, you can specify traffic behavior for one or more hostnames. Routing rules in the virtual service tell {ProductName} how to send the traffic for the virtual service to appropriate destinations. Route destinations can be versions of the same service or entirely different services. +Without virtual services, {SMProductName} distributes traffic using round-robin load balancing between all service instances. With a virtual service, you can specify traffic behavior for one or more hostnames. Routing rules in the virtual service tell {SMProductName} how to send the traffic for the virtual service to appropriate destinations. Route destinations can be versions of the same service or entirely different services. .Procedure @@ -102,7 +102,7 @@ spec: .Destination -The `destination` field in the route section specifies the actual destination for traffic that matches this condition. Unlike the virtual service's host, the destination's host must be a real destination that exists in the {ProductName} service registry. This can be a mesh service with proxies or a non-mesh service added using a service entry. In this example, the hostname is a Kubernetes service name: +The `destination` field in the route section specifies the actual destination for traffic that matches this condition. Unlike the virtual service's host, the destination's host must be a real destination that exists in the {SMProductName} service registry. This can be a mesh service with proxies or a non-mesh service added using a service entry. In this example, the hostname is a Kubernetes service name: [source,yaml] ---- @@ -128,7 +128,7 @@ Destination rules are applied after virtual service routing rules are evaluated, [id="ossm-routing-lb_{context}"] ==== Load balancing options -By default, {ProductName} uses a round-robin load balancing policy, where each service instance in the pool gets a request in turn. {ProductName} also supports the following models, which you can specify in destination rules for requests to a particular service or service subset. +By default, {SMProductName} uses a round-robin load balancing policy, where each service instance in the pool gets a request in turn. {SMProductName} also supports the following models, which you can specify in destination rules for requests to a particular service or service subset. * Random: Requests are forwarded at random to instances in the pool. * Weighted: Requests are forwarded to instances in the pool according to a specific percentage. @@ -169,7 +169,7 @@ spec: You can use a gateway to manage inbound and outbound traffic for your mesh to specify which traffic you want to enter or leave the mesh. Gateway configurations are applied to standalone Envoy proxies that are running at the edge of the mesh, rather than sidecar Envoy proxies running alongside your service workloads. -Unlike other mechanisms for controlling traffic entering your systems, such as the Kubernetes Ingress APIs, {ProductName} gateways allow you use the full power and flexibility of traffic routing. The {ProductName} gateway resource can layer 4-6 load balancing properties such as ports to expose and configure {ProductName} TLS settings. Instead of adding application-layer traffic routing (L7) to the same API resource, you can bind a regular {ProductName} virtual service to the gateway and manage gateway traffic like any other data plane traffic in a service mesh. +Unlike other mechanisms for controlling traffic entering your systems, such as the Kubernetes Ingress APIs, {SMProductName} gateways allow you use the full power and flexibility of traffic routing. The {SMProductName} gateway resource can layer 4-6 load balancing properties such as ports to expose and configure {SMProductName} TLS settings. Instead of adding application-layer traffic routing (L7) to the same API resource, you can bind a regular {SMProductName} virtual service to the gateway and manage gateway traffic like any other data plane traffic in a service mesh. Gateways are primarily used to manage ingress traffic, but you can also configure egress gateways. An egress gateway enables you to configure a dedicated exit node for the traffic leaving the mesh. This enables you to limit which services have access to external networks, which adds security control to your service mesh. You can also use a gateway to configure a purely internal proxy. @@ -221,7 +221,7 @@ You can then configure the virtual service with routing rules for the external t [id="ossm-routing-se_{context}"] === Service entries -A service entry adds an entry to the service registry that {ProductName} maintains internally. After you add the service entry, the Envoy proxies send traffic to the service as if it is a service in your mesh. Service entries allow you to do the following: +A service entry adds an entry to the service registry that {SMProductName} maintains internally. After you add the service entry, the Envoy proxies send traffic to the service as if it is a service in your mesh. Service entries allow you to do the following: * Manage traffic for services that run outside of the service mesh. * Redirect and forward traffic for external destinations (such as, APIs consumed from the web) or traffic to services in legacy infrastructure. @@ -230,11 +230,11 @@ A service entry adds an entry to the service registry that {ProductName} maintai [NOTE] ==== -Add services from a different cluster to the mesh to configure a multicluster {ProductName} mesh on Kubernetes. +Add services from a different cluster to the mesh to configure a multicluster {SMProductName} mesh on Kubernetes. ==== .Service entry examples -The following example mesh-external service entry adds the `ext-resource` external dependency to the {ProductName} service registry: +The following example mesh-external service entry adds the `ext-resource` external dependency to the {SMProductName} service registry: [source,yaml] ---- diff --git a/modules/ossm-security-cert-manage-1x.adoc b/modules/ossm-security-cert-manage-1x.adoc index 839ed8a84a89..dfb130842f5c 100644 --- a/modules/ossm-security-cert-manage-1x.adoc +++ b/modules/ossm-security-cert-manage-1x.adoc @@ -6,11 +6,11 @@ [id="ossm-cert-manage_{context}"] = Adding an external certificate authority key and certificate -By default, {ProductName} generates self-signed root certificate and key, and uses them to sign the workload certificates. You can also use the user-defined certificate and key to sign workload certificates, with user-defined root certificate. This task demonstrates an example to plug certificates and key into {ProductShortName}. +By default, {SMProductName} generates self-signed root certificate and key, and uses them to sign the workload certificates. You can also use the user-defined certificate and key to sign workload certificates, with user-defined root certificate. This task demonstrates an example to plug certificates and key into {SMProductShortName}. .Prerequisites -* You must have installed {ProductName} with mutual TLS enabled to configure certificates. +* You must have installed {SMProductName} with mutual TLS enabled to configure certificates. * This example uses the certificates from the link:https://github.com/maistra/istio/tree/maistra-2.0/samples/certs[Maistra repository]. For production, use your own certificates from your certificate authority. * You must deploy the Bookinfo sample application to verify the results with these instructions. @@ -19,7 +19,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-1.1/samples/certs[Maistra repo] locally and replace `` with the path to your certificates. +Add the certificates to {SMProductShortName} by following these steps. Save the example certificates from the link:https://github.com/maistra/istio/tree/maistra-1.1/samples/certs[Maistra repo] locally and replace `` 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`. + @@ -30,7 +30,7 @@ $ oc create secret generic cacerts -n istio-system --from-file=/ca-cert.pe --from-file=/cert-chain.pem ---- + -. In the `ServiceMeshControlPlane` resource set `global.mtls.enabled` to `true` and `security.selfSigned` set to `false`. {ProductShortName} reads the certificates and key from the secret-mount files. +. In the `ServiceMeshControlPlane` resource set `global.mtls.enabled` to `true` and `security.selfSigned` set to `false`. {SMProductShortName} reads the certificates and key from the secret-mount files. + [source,yaml] ---- @@ -45,7 +45,7 @@ spec: selfSigned: false ---- + -. To make sure the workloads add the new certificates promptly, delete the secrets generated by {ProductShortName}, named `istio.*`. In this example, `istio.default`. {ProductShortName} issues new certificates for the workloads. +. To make sure the workloads add the new certificates promptly, delete the secrets generated by {SMProductShortName}, named `istio.*`. In this example, `istio.default`. {SMProductShortName} issues new certificates for the workloads. + [source,terminal] ---- @@ -153,7 +153,7 @@ To remove the certificates you added, follow these steps. $ oc delete secret cacerts -n istio-system ---- + -. Redeploy {ProductShortName} with a self-signed root certificate in the `ServiceMeshControlPlane` resource. +. Redeploy {SMProductShortName} with a self-signed root certificate in the `ServiceMeshControlPlane` resource. + [source,yaml] ---- diff --git a/modules/ossm-security-cert-manage.adoc b/modules/ossm-security-cert-manage.adoc index 4b82e56297b9..a6f21dcfdb5d 100644 --- a/modules/ossm-security-cert-manage.adoc +++ b/modules/ossm-security-cert-manage.adoc @@ -5,11 +5,11 @@ [id="ossm-cert-manage_{context}"] = Adding an external certificate authority key and certificate -By default, {ProductName} generates a self-signed root certificate and key and uses them to sign the workload certificates. You can also use the user-defined certificate and key to sign workload certificates with user-defined root certificate. This task demonstrates an example to plug certificates and key into {ProductShortName}. +By default, {SMProductName} generates a self-signed root certificate and key and uses them to sign the workload certificates. You can also use the user-defined certificate and key to sign workload certificates with user-defined root certificate. This task demonstrates an example to plug certificates and key into {SMProductShortName}. .Prerequisites -* Install {ProductName} with mutual TLS enabled to configure certificates. +* Install {SMProductName} with mutual TLS enabled to configure certificates. * This example uses the certificates from the link:https://github.com/maistra/istio/tree/maistra-{MaistraVersion}/samples/certs[Maistra repository]. For production, use your own certificates from your certificate authority. * Deploy the Bookinfo sample application to verify the results with these instructions. @@ -18,7 +18,7 @@ By default, {ProductName} generates a self-signed root certificate and key and u 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 named `ca-cert.pem`, the key is `ca-key.pem`, and the root certificate, which signs `ca-cert.pem`, is named `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-{MaistraVersion}/samples/certs[Maistra repository] locally and replace `` with the path to your certificates. +Add the certificates to {SMProductShortName} by following these steps. Save the example certificates from the link:https://github.com/maistra/istio/tree/maistra-{MaistraVersion}/samples/certs[Maistra repository] locally and replace `` 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`. + @@ -29,7 +29,7 @@ $ oc create secret generic cacerts -n istio-system --from-file=/ca-cert.pe --from-file=/cert-chain.pem ---- + -. In the `ServiceMeshControlPlane` resource set `spec.security.dataPlane.mtls: true` to `true` and configure your certificateAuthority like the following example. The default `rootCADir` is `/etc/cacerts`. You do not need to set the `privateKey` if the key and certs are mounted in the default location. {ProductShortName} reads the certificates and key from the secret-mount files. +. In the `ServiceMeshControlPlane` resource set `spec.security.dataPlane.mtls: true` to `true` and configure your certificateAuthority like the following example. The default `rootCADir` is `/etc/cacerts`. You do not need to set the `privateKey` if the key and certs are mounted in the default location. {SMProductShortName} reads the certificates and key from the secret-mount files. + [source,yaml] ---- @@ -148,7 +148,7 @@ To remove the certificates you added, follow these steps. $ oc delete secret cacerts -n istio-system ---- + -. Redeploy {ProductShortName} with a self-signed root certificate in the `ServiceMeshControlPlane` resource. +. Redeploy {SMProductShortName} with a self-signed root certificate in the `ServiceMeshControlPlane` resource. + [source,yaml] ---- diff --git a/modules/ossm-security-mtls-1x.adoc b/modules/ossm-security-mtls-1x.adoc index a1ef5202c51e..3b2441f2bbc0 100644 --- a/modules/ossm-security-mtls-1x.adoc +++ b/modules/ossm-security-mtls-1x.adoc @@ -9,7 +9,7 @@ Mutual Transport Layer Security (mTLS) is a protocol where two parties authentic mTLS can be used without changes to the application or service code. The TLS is handled entirely by the service mesh infrastructure and between the two sidecar proxies. -By default, {ProductName} is set to permissive mode, where the sidecars in {ProductShortName} accept both plain-text traffic and connections that are encrypted using mTLS. If a service in your mesh is communicating with a service outside the mesh, strict mTLS could break communication between those services. Use permissive mode while you migrate your workloads to {ProductShortName}. +By default, {SMProductName} is set to permissive mode, where the sidecars in {SMProductShortName} accept both plain-text traffic and connections that are encrypted using mTLS. If a service in your mesh is communicating with a service outside the mesh, strict mTLS could break communication between those services. Use permissive mode while you migrate your workloads to {SMProductShortName}. [id="ossm-security-enabling-strict-mtls_{context}"] == Enabling strict mTLS across the mesh @@ -47,7 +47,7 @@ spec: [id="ossm-security-mtls-sidecars-outgoing_{context}"] == Configuring sidecars for outgoing connections -Create a destination rule to configure {ProductShortName} to use mTLS when sending requests to other services in the mesh. +Create a destination rule to configure {SMProductShortName} to use mTLS when sending requests to other services in the mesh. [source,yaml] ---- diff --git a/modules/ossm-security-mtls.adoc b/modules/ossm-security-mtls.adoc index 700b5566c508..a198293825d3 100644 --- a/modules/ossm-security-mtls.adoc +++ b/modules/ossm-security-mtls.adoc @@ -7,6 +7,6 @@ Mutual Transport Layer Security (mTLS) is a protocol that enables two parties authenticate each other. It is the default mode of authentication in some protocols (IKE, SSH) and optional in others (TLS). mTLS can be used without changes to the application or service code. The TLS is handled entirely by the service mesh infrastructure and between the two sidecar proxies. -By default, mTLS in {ProductName} is enabled and set to permissive mode, where the sidecars in {ProductShortName} accept both plain-text traffic and connections that are encrypted using mTLS. If a service in your mesh is communicating with a service outside the mesh, strict mTLS could break communication between those services. Use permissive mode while you migrate your workloads to {ProductShortName}. Then, you can enable strict mTLS across your mesh, namespace, or application. +By default, mTLS in {SMProductName} is enabled and set to permissive mode, where the sidecars in {SMProductShortName} accept both plain-text traffic and connections that are encrypted using mTLS. If a service in your mesh is communicating with a service outside the mesh, strict mTLS could break communication between those services. Use permissive mode while you migrate your workloads to {SMProductShortName}. Then, you can enable strict mTLS across your mesh, namespace, or application. Enabling mTLS across your mesh at the control plane level secures all the traffic in your service mesh without rewriting your applications and workloads. You can secure namespaces in your mesh at the data plane level in the `ServiceMeshControlPlane` resource. To customize traffic encryption connections, configure namespaces at the application level with `PeerAuthentication` and `DestinationRule` resources. diff --git a/modules/ossm-servicemesh-overview.adoc b/modules/ossm-servicemesh-overview.adoc index 74384b26d9dc..81e11c6213e8 100644 --- a/modules/ossm-servicemesh-overview.adoc +++ b/modules/ossm-servicemesh-overview.adoc @@ -4,10 +4,10 @@ Module included in the following assemblies: //// [id="ossm-servicemesh-overview_{context}"] -= Introduction to {ProductName} += Introduction to {SMProductName} -{ProductName} addresses a variety of problems in a microservice architecture by creating a centralized point of control in an application. It adds a transparent layer on existing distributed applications without requiring any changes to the application code. +{SMProductName} addresses a variety of problems in a microservice architecture by creating a centralized point of control in an application. It adds a transparent layer on existing distributed applications without requiring any changes to the application code. -Microservice architectures split the work of enterprise applications into modular services, which can make scaling and maintenance easier. However, as an enterprise application built on a microservice architecture grows in size and complexity, it becomes difficult to understand and manage. {ProductShortName} can address those architecture problems by capturing or intercepting traffic between services and can modify, redirect, or create new requests to other services. +Microservice architectures split the work of enterprise applications into modular services, which can make scaling and maintenance easier. However, as an enterprise application built on a microservice architecture grows in size and complexity, it becomes difficult to understand and manage. {SMProductShortName} can address those architecture problems by capturing or intercepting traffic between services and can modify, redirect, or create new requests to other services. -{ProductShortName}, which is based on the open source link:https://istio.io/[Istio project], provides an easy way to create a network of deployed services that provides discovery, load balancing, service-to-service authentication, failure recovery, metrics, and monitoring. A service mesh also provides more complex operational functionality, including A/B testing, canary releases, access control, and end-to-end authentication. +{SMProductShortName}, which is based on the open source link:https://istio.io/[Istio project], provides an easy way to create a network of deployed services that provides discovery, load balancing, service-to-service authentication, failure recovery, metrics, and monitoring. A service mesh also provides more complex operational functionality, including A/B testing, canary releases, access control, and end-to-end authentication. diff --git a/modules/ossm-smcp-prod.adoc b/modules/ossm-smcp-prod.adoc index eb8e3624d089..9fcf25612eae 100644 --- a/modules/ossm-smcp-prod.adoc +++ b/modules/ossm-smcp-prod.adoc @@ -6,7 +6,7 @@ [id="ossm-smcp-prod_{context}"] = Configuring your ServiceMeshControlPlane resource for production -If you have installed a basic `ServiceMeshControlPlane` resource to test {ProductShortName}, you must configure it to production specification before you use {ProductName} in production. +If you have installed a basic `ServiceMeshControlPlane` resource to test {SMProductShortName}, you must configure it to production specification before you use {SMProductName} in production. You cannot change the `metadata.name` field of an existing `ServiceMeshControlPlane` resource. For production deployments, you must customize the default template. diff --git a/modules/ossm-supported-configurations-v1x.adoc b/modules/ossm-supported-configurations-v1x.adoc index 8dfc630cebcc..11a0e843f68e 100644 --- a/modules/ossm-supported-configurations-v1x.adoc +++ b/modules/ossm-supported-configurations-v1x.adoc @@ -5,26 +5,26 @@ // * post_installation_configuration/network-configuration.adoc [id="ossm-supported-configurations-v1x_{context}"] -= {ProductName} supported configurations += {SMProductName} supported configurations -The following are the only supported configurations for the {ProductName}: +The following are the only supported configurations for the {SMProductName}: * Red Hat {product-title} version 4.x. [NOTE] ==== -OpenShift Online and OpenShift Dedicated are not supported for {ProductName}. +OpenShift Online and OpenShift Dedicated are not supported for {SMProductName}. ==== * The deployment must be contained to a single {product-title} cluster that is not federated. -* This release of {ProductName} is only available on {product-title} x86_64. -* This release only supports configurations where all {ProductShortName} components are contained in the {product-title} cluster in which it operates. It does not support management of microservices that reside outside of the cluster, or in a multi-cluster scenario. +* This release of {SMProductName} is only available on {product-title} x86_64. +* This release only supports configurations where all {SMProductShortName} components are contained in the {product-title} cluster in which it operates. It does not support management of microservices that reside outside of the cluster, or in a multi-cluster scenario. * This release only supports configurations that do not integrate external services such as virtual machines. -For additional information about {ProductName} lifecycle and supported configurations, refer to the link:https://access.redhat.com/support/policy/updates/openshift#ossm[Support Policy]. +For additional information about {SMProductName} lifecycle and supported configurations, refer to the link:https://access.redhat.com/support/policy/updates/openshift#ossm[Support Policy]. [id="ossm-supported-configurations-kiali_{context}"] -== Supported configurations for Kiali on {ProductName} +== Supported configurations for Kiali on {SMProductName} * The Kiali observability console is only supported on the two most recent releases of the Chrome, Edge, Firefox, or Safari browsers. diff --git a/modules/ossm-supported-configurations.adoc b/modules/ossm-supported-configurations.adoc index e446c49da5e3..b6180e42c61b 100644 --- a/modules/ossm-supported-configurations.adoc +++ b/modules/ossm-supported-configurations.adoc @@ -7,7 +7,7 @@ [id="ossm-supported-configurations_{context}"] = Supported configurations -The following configurations are supported for the current release of {ProductName}: +The following configurations are supported for the current release of {SMProductName}: * Red Hat {product-title} version 4.x. * Red Hat {product-dedicated} version 4. @@ -15,25 +15,25 @@ The following configurations are supported for the current release of {ProductNa [NOTE] ==== -Red Hat OpenShift Online is not supported for {ProductName}. +Red Hat OpenShift Online is not supported for {SMProductName}. ==== -* This release of {ProductName} is only available on {product-title} x86_64, IBM Z, and IBM Power Systems. +* This release of {SMProductName} is only available on {product-title} x86_64, IBM Z, and IBM Power Systems. ** IBM Z is only supported on {product-title} 4.6 and later. ** IBM Power Systems is only supported on {product-title} 4.6 and later. -* Configurations where all {ProductShortName} components are contained within a single {product-title} cluster. {ProductName} does not support management of microservices that reside outside of the cluster within which {ProductShortName} is running. +* Configurations where all {SMProductShortName} components are contained within a single {product-title} cluster. {SMProductName} does not support management of microservices that reside outside of the cluster within which {SMProductShortName} is running. * Configurations that do not integrate external services such as virtual machines. -For additional information about {ProductName} lifecycle and supported configurations, refer to the link:https://access.redhat.com/support/policy/updates/openshift#ossm[Support Policy]. +For additional information about {SMProductName} lifecycle and supported configurations, refer to the link:https://access.redhat.com/support/policy/updates/openshift#ossm[Support Policy]. [id="ossm-supported-configurations-networks_{context}"] == Supported network configurations -{ProductName} supports the following network configurations. +{SMProductName} supports the following network configurations. * OpenShift-SDN * OVN-Kubernetes is supported on {product-title} 4.7.32+, {product-title} 4.8.12+, and {product-title} 4.9+. -* Third-Party Container Network Interface (CNI) plug-ins that have been certified on {product-title} and passed {ProductShortName} conformance testing. See link:https://access.redhat.com/articles/5436171[Certified OpenShift CNI Plug-ins] for more information. +* Third-Party Container Network Interface (CNI) plug-ins that have been certified on {product-title} and passed {SMProductShortName} conformance testing. See link:https://access.redhat.com/articles/5436171[Certified OpenShift CNI Plug-ins] for more information. [id="ossm-supported-configurations-kiali_{context}"] == Supported configurations for Kiali diff --git a/modules/ossm-threescale-applying-external-service-entry-objects.adoc b/modules/ossm-threescale-applying-external-service-entry-objects.adoc index 4cdbaaaa314a..327cdf846a90 100644 --- a/modules/ossm-threescale-applying-external-service-entry-objects.adoc +++ b/modules/ossm-threescale-applying-external-service-entry-objects.adoc @@ -6,9 +6,9 @@ [id="ossm-threescale-applying-external-service-entry-objects_{context}"] = Applying 3scale external ServiceEntry objects -To have the `threescale-wasm-auth` module authorize requests against 3scale, the module must have access to 3scale services. You can accomplish this within {ProductName} and Istio by applying an external `ServiceEntry` object. +To have the `threescale-wasm-auth` module authorize requests against 3scale, the module must have access to 3scale services. You can accomplish this within {SMProductName} and Istio by applying an external `ServiceEntry` object. -The custom resources set up the service entries for access from within {ProductShortName} to 3scale Hosted (SaaS) for the backend and system components of the Service Management API and the Account Management API. The Service Management API receives queries for the authorization status of each request. The Account Management API provides API management configuration settings for your services. +The custom resources set up the service entries for access from within {SMProductShortName} to 3scale Hosted (SaaS) for the backend and system components of the Service Management API and the Account Management API. The Service Management API receives queries for the authorization status of each request. The Account Management API provides API management configuration settings for your services. .Procedure diff --git a/modules/ossm-threescale-authentication.adoc b/modules/ossm-threescale-authentication.adoc index 0945d19abdff..dc58aae5f1a6 100644 --- a/modules/ossm-threescale-authentication.adoc +++ b/modules/ossm-threescale-authentication.adoc @@ -26,9 +26,9 @@ When specifying values from headers, they must be lower case. For example, if yo [id="ossm-threescale-apikey-authentication_{context}"] === API key authentication method -{ProductShortName} looks for the API key in query parameters and request headers as specified in the `user` option in the `subject` custom resource parameter. It checks the values in the order given in the custom resource file. You can restrict the search for the API key to either query parameters or request headers by omitting the unwanted option. +{SMProductShortName} looks for the API key in query parameters and request headers as specified in the `user` option in the `subject` custom resource parameter. It checks the values in the order given in the custom resource file. You can restrict the search for the API key to either query parameters or request headers by omitting the unwanted option. -In this example, {ProductShortName} looks for the API key in the `user_key` query parameter. If the API key is not in the query parameter, {ProductShortName} then checks the `user-key` header. +In this example, {SMProductShortName} looks for the API key in the `user_key` query parameter. If the API key is not in the query parameter, {SMProductShortName} then checks the `user-key` header. .API key authentication method example @@ -53,9 +53,9 @@ If you want the adapter to examine a different query parameter or request header [id="ossm-threescale-appidapikey-authentication_{context}"] === Application ID and application key pair authentication method -{ProductShortName} looks for the application ID and application key in query parameters and request headers, as specified in the `properties` option in the `subject` custom resource parameter. The application key is optional. It checks the values in the order given in the custom resource file. You can restrict the search for the credentials to either query parameters or request headers by not including the unwanted option. +{SMProductShortName} looks for the application ID and application key in query parameters and request headers, as specified in the `properties` option in the `subject` custom resource parameter. The application key is optional. It checks the values in the order given in the custom resource file. You can restrict the search for the credentials to either query parameters or request headers by not including the unwanted option. -In this example, {ProductShortName} looks for the application ID and application key in the query parameters first, moving on to the request headers if needed. +In this example, {SMProductShortName} looks for the application ID and application key in the query parameters first, moving on to the request headers if needed. .Application ID and application key pair authentication method example @@ -132,9 +132,9 @@ spec: [id="ossm-threescale-hybrid-authentication_{context}"] === Hybrid authentication method -You can choose to not enforce a particular authentication method and accept any valid credentials for either method. If both an API key and an application ID/application key pair are provided, {ProductShortName} uses the API key. +You can choose to not enforce a particular authentication method and accept any valid credentials for either method. If both an API key and an application ID/application key pair are provided, {SMProductShortName} uses the API key. -In this example, {ProductShortName} checks for an API key in the query parameters, then the request headers. If there is no API key, it then checks for an application ID and key in the query parameters, then the request headers. +In this example, {SMProductShortName} checks for an API key in the query parameters, then the request headers. If there is no API key, it then checks for an application ID and key in the query parameters, then the request headers. .Hybrid authentication method example diff --git a/modules/ossm-threescale-integrate-1x.adoc b/modules/ossm-threescale-integrate-1x.adoc index 82154a2814a8..5013ce306e20 100644 --- a/modules/ossm-threescale-integrate-1x.adoc +++ b/modules/ossm-threescale-integrate-1x.adoc @@ -5,21 +5,21 @@ :_content-type: PROCEDURE [id="ossm-threescale-integrate-1x_{context}"] -= Integrate the 3scale adapter with {ProductName} += Integrate the 3scale adapter with {SMProductName} You can use these examples to configure requests to your services using the 3scale Istio Adapter. .Prerequisites: -* {ProductName} version 1.x +* {SMProductName} version 1.x * A working 3scale account (link:https://www.3scale.net/signup/[SaaS] or link:https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.5/html/installing_3scale/onpremises-installation[3scale 2.5 On-Premises]) * Enabling backend cache requires 3scale 2.9 or greater -* {ProductName} prerequisites +* {SMProductName} prerequisites [NOTE] ==== -To configure the 3scale Istio Adapter, refer to {ProductName} custom resources for instructions on adding adapter parameters to the custom resource file. +To configure the 3scale Istio Adapter, refer to {SMProductName} custom resources for instructions on adding adapter parameters to the custom resource file. ==== diff --git a/modules/ossm-threescale-integrate.adoc b/modules/ossm-threescale-integrate.adoc index c40bc403c571..db061da4521e 100644 --- a/modules/ossm-threescale-integrate.adoc +++ b/modules/ossm-threescale-integrate.adoc @@ -5,24 +5,24 @@ :_content-type: PROCEDURE [id="ossm-threescale-integrate_{context}"] -= Integrate the 3scale adapter with {ProductName} += Integrate the 3scale adapter with {SMProductName} You can use these examples to configure requests to your services using the 3scale Istio Adapter. .Prerequisites: -* {ProductName} version 2.x +* {SMProductName} version 2.x * A working 3scale account (link:https://www.3scale.net/signup/[SaaS] or link:https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.9/html/installing_3scale/install-threescale-on-openshift-guide[3scale 2.9 On-Premises]) * Enabling backend cache requires 3scale 2.9 or greater -* {ProductName} prerequisites +* {SMProductName} prerequisites * Ensure Mixer policy enforcement is enabled. Update Mixer policy enforcement section provides instructions to check the current Mixer policy enforcement status and enable policy enforcement. * Mixer policy and telemetry must be enabled if you are using a mixer plug-in. ** You will need to properly configure the Service Mesh Control Plane (SMCP) when upgrading. [NOTE] ==== -To configure the 3scale Istio Adapter, refer to {ProductName} custom resources for instructions on adding adapter parameters to the custom resource file. +To configure the 3scale Istio Adapter, refer to {SMProductName} custom resources for instructions on adding adapter parameters to the custom resource file. ==== diff --git a/modules/ossm-threescale-integration-settings.adoc b/modules/ossm-threescale-integration-settings.adoc index 609e35863306..b3a92dfc8a21 100644 --- a/modules/ossm-threescale-integration-settings.adoc +++ b/modules/ossm-threescale-integration-settings.adoc @@ -11,7 +11,7 @@ Follow this procedure to configure the 3scale integration settings. [NOTE] ==== -For 3scale SaaS customers, {ProductName} is enabled as part of the Early Access program. +For 3scale SaaS customers, {SMProductName} is enabled as part of the Early Access program. ==== .Procedure diff --git a/modules/ossm-threescale-webassembly-module-configuration.adoc b/modules/ossm-threescale-webassembly-module-configuration.adoc index 922c6f485aa7..dbd4ea00e916 100644 --- a/modules/ossm-threescale-webassembly-module-configuration.adoc +++ b/modules/ossm-threescale-webassembly-module-configuration.adoc @@ -13,6 +13,6 @@ If you use the `Proxy-WASM` module in stand-alone mode, you must write the confi [IMPORTANT] ==== -The `EnvoyFilter` custom resource is not a supported API, although it can be used in some 3scale Istio adapter or {ProductShortName} releases. Using the `EnvoyFilter` custom resource is not recommended. Use the `ServiceMeshExtension` API instead of the `EnvoyFilter` custom resource. +The `EnvoyFilter` custom resource is not a supported API, although it can be used in some 3scale Istio adapter or {SMProductShortName} releases. Using the `EnvoyFilter` custom resource is not recommended. Use the `ServiceMeshExtension` API instead of the `EnvoyFilter` custom resource. If you must use the `EnvoyFilter` custom resource, you must specify the spec in JSON format. ==== 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 index c9ac62d580b4..43a1d0c0c048 100644 --- a/modules/ossm-threescale-webassembly-module-examples-for-credentials-use-cases.adoc +++ b/modules/ossm-threescale-webassembly-module-examples-for-credentials-use-cases.adoc @@ -158,7 +158,7 @@ Then use one of the following possibilities: [id="openid-connect-use-case_{context}"] == OpenID Connect (OIDC) use case -For {ProductShortName} and the 3scale Istio adapter, you must deploy a `RequestAuthentication` as shown in the following example, filling in your own workload data and `jwtRules`: +For {SMProductShortName} and the 3scale Istio adapter, you must deploy a `RequestAuthentication` as shown in the following example, filling in your own workload data and `jwtRules`: [source,yaml] ---- diff --git a/modules/ossm-threescale-webassembly-module-upstream-object.adoc b/modules/ossm-threescale-webassembly-module-upstream-object.adoc index 56e4ca540e23..f6784c65cf11 100644 --- a/modules/ossm-threescale-webassembly-module-upstream-object.adoc +++ b/modules/ossm-threescale-webassembly-module-upstream-object.adoc @@ -22,7 +22,7 @@ upstream: |Name |Description |Required a|`name` -a|`name` is not a free-form identifier. It is the identifier for the external host as defined by the proxy configuration. In the case of stand-alone `Envoy` configurations, it maps to the name of a link:https://www.envoyproxy.io/docs/envoy/v1.19.0/api-v3/config/cluster/v3/cluster.proto#config-cluster-v3-cluster[Cluster], also known as `upstream` in other proxies. *Note:* the value of this field, because the {ProductShortName} and 3scale Istio adapter control plane configure the name according to a format using a vertical bar (\|) as the separator of multiple fields. For the purposes of this integration, always use the format: `outbound\|\|\|`. +a|`name` is not a free-form identifier. It is the identifier for the external host as defined by the proxy configuration. In the case of stand-alone `Envoy` configurations, it maps to the name of a link:https://www.envoyproxy.io/docs/envoy/v1.19.0/api-v3/config/cluster/v3/cluster.proto#config-cluster-v3-cluster[Cluster], also known as `upstream` in other proxies. *Note:* the value of this field, because the {SMProductShortName} and 3scale Istio adapter control plane configure the name according to a format using a vertical bar (\|) as the separator of multiple fields. For the purposes of this integration, always use the format: `outbound\|\|\|`. |Yes a|`url` diff --git a/modules/ossm-troubleshooting-injection.adoc b/modules/ossm-troubleshooting-injection.adoc index 188f16d26005..51d59d78c770 100644 --- a/modules/ossm-troubleshooting-injection.adoc +++ b/modules/ossm-troubleshooting-injection.adoc @@ -4,7 +4,7 @@ [id="ossm-troubleshooting-injection_{context}"] = Troubleshooting sidecar injection -{ProductName} does not automatically inject proxy sidecars to pods. You must opt in to sidecar injection. +{SMProductName} does not automatically inject proxy sidecars to pods. You must opt in to sidecar injection. == Troubleshooting Istio sidecar injection diff --git a/modules/ossm-troubleshooting-operators.adoc b/modules/ossm-troubleshooting-operators.adoc index c7ca1b3b2bd2..3d3fc82d57db 100644 --- a/modules/ossm-troubleshooting-operators.adoc +++ b/modules/ossm-troubleshooting-operators.adoc @@ -9,7 +9,7 @@ If you experience Operator issues: * Verify your Operator subscription status. * Verify that you did not install a community version of the Operator, instead of the supported Red Hat version. -* Verify that you have the `cluster-admin` role to install {ProductName}. +* Verify that you have the `cluster-admin` role to install {SMProductName}. * Check for any errors in the Operator pod logs if the issue is related to installation of Operators. [NOTE] diff --git a/modules/ossm-tutorial-bookinfo-install.adoc b/modules/ossm-tutorial-bookinfo-install.adoc index c8cd76e07308..efb42014616a 100644 --- a/modules/ossm-tutorial-bookinfo-install.adoc +++ b/modules/ossm-tutorial-bookinfo-install.adoc @@ -8,12 +8,12 @@ This PROCEDURE module included in the following assemblies: [id="ossm-tutorial-bookinfo-install_{context}"] = Installing the Bookinfo application -This tutorial walks you through how to create a sample application by creating a project, deploying the Bookinfo application to that project, and viewing the running application in {ProductShortName}. +This tutorial walks you through how to create a sample application by creating a project, deploying the Bookinfo application to that project, and viewing the running application in {SMProductShortName}. .Prerequisites: * {product-title} 4.1 or higher installed. -* {ProductName} {ProductVersion} installed. +* {SMProductName} {SMProductVersion} installed. * Access to the OpenShift CLI (`oc`). * An account with the `cluster-admin` role. @@ -48,7 +48,7 @@ $ oc new-project bookinfo . Click the *Project* menu and use the control plane namespace. In this example, use `istio-system`. -. Click the *{ProductName}* Operator. +. Click the *{SMProductName}* Operator. . Click the *Istio Service Mesh Member Roll* tab. diff --git a/modules/ossm-tutorial-bookinfo-overview.adoc b/modules/ossm-tutorial-bookinfo-overview.adoc index 88e64a99daf3..68959a19b8da 100644 --- a/modules/ossm-tutorial-bookinfo-overview.adoc +++ b/modules/ossm-tutorial-bookinfo-overview.adoc @@ -7,7 +7,7 @@ This CONCEPT module included in the following assemblies: [id="ossm-tutorial-bookinfo-overview_{context}"] = Bookinfo example application -The Bookinfo example application allows you to test your {ProductName} {ProductVersion} installation on {product-title}. +The Bookinfo example application allows you to test your {SMProductName} {SMProductVersion} installation on {product-title}. The Bookinfo application displays information about a book, similar to a single catalog entry of an online book store. The application displays a page that describes the book, book details (ISBN, number of pages, and other information), and book reviews. diff --git a/modules/ossm-tutorial-bookinfo-removing.adoc b/modules/ossm-tutorial-bookinfo-removing.adoc index fc2241fc4ab2..51e9e98a789f 100644 --- a/modules/ossm-tutorial-bookinfo-removing.adoc +++ b/modules/ossm-tutorial-bookinfo-removing.adoc @@ -13,7 +13,7 @@ Follow these steps to remove the Bookinfo application. .Prerequisites * {product-title} 4.1 or higher installed. -* {ProductName} {ProductVersion} installed. +* {SMProductName} {SMProductVersion} installed. * Access to the OpenShift CLI (`oc`). [id="ossm-delete-bookinfo-project_{context}"] @@ -37,7 +37,7 @@ $ oc delete project bookinfo ---- [id="ossm-remove-bookinfo-smmr_{context}"] -== Remove the Bookinfo project from the {ProductShortName} member roll +== Remove the Bookinfo project from the {SMProductShortName} member roll .Procedure @@ -47,7 +47,7 @@ $ oc delete project bookinfo . Click the *Project* menu and choose `openshift-operators` from the list. -. Click the *Istio Service Mesh Member Roll* link under *Provided APIS* for the *{ProductName}* Operator. +. Click the *Istio Service Mesh Member Roll* link under *Provided APIS* for the *{SMProductName}* Operator. . Click the `ServiceMeshMemberRoll` menu {kebab} and select *Edit Service Mesh Member Roll*. diff --git a/modules/ossm-tutorial-bookinfo-verify-install.adoc b/modules/ossm-tutorial-bookinfo-verify-install.adoc index 07bcb397c9a7..a0dc7d664e7d 100644 --- a/modules/ossm-tutorial-bookinfo-verify-install.adoc +++ b/modules/ossm-tutorial-bookinfo-verify-install.adoc @@ -12,7 +12,7 @@ To confirm that the sample Bookinfo application was successfully deployed, perfo .Prerequisites -* {ProductName} {ProductVersion} installed. +* {SMProductName} {SMProductVersion} installed. * Access to the OpenShift CLI (`oc`). * Complete the steps for installing the Bookinfo sample app. diff --git a/modules/ossm-tutorial-grafana-accessing.adoc b/modules/ossm-tutorial-grafana-accessing.adoc index 170fb9f70aa0..f7391cbe0512 100644 --- a/modules/ossm-tutorial-grafana-accessing.adoc +++ b/modules/ossm-tutorial-grafana-accessing.adoc @@ -11,7 +11,7 @@ The Grafana dashboard's web-based interface lets you visualize your metrics data .Prerequisites: * {product-title} 3.11 or higher installed. -* {ProductName} {ProductVersion} installed. +* {SMProductName} {SMProductVersion} installed. * `Bookinfo` demonstration application installed. .Procedure diff --git a/modules/ossm-tutorial-jaeger-generating-traces.adoc b/modules/ossm-tutorial-jaeger-generating-traces.adoc index 549ea5e45b58..6aa86f3b77f8 100644 --- a/modules/ossm-tutorial-jaeger-generating-traces.adoc +++ b/modules/ossm-tutorial-jaeger-generating-traces.adoc @@ -8,14 +8,14 @@ This module is included in the following assemblies: [id="generating-sample-traces-analyzing-trace-data_{context}"] = Generating example traces and analyzing trace data -Jaeger is an open source distributed tracing system. With Jaeger, you can perform a trace that follows the path of a request through various microservices which make up an application. Jaeger is installed by default as part of the {ProductShortName}. +Jaeger is an open source distributed tracing system. With Jaeger, you can perform a trace that follows the path of a request through various microservices which make up an application. Jaeger is installed by default as part of the {SMProductShortName}. -This tutorial uses {ProductShortName} and the Bookinfo sample application to demonstrate how you can use Jaeger to perform distributed tracing. +This tutorial uses {SMProductShortName} and the Bookinfo sample application to demonstrate how you can use Jaeger to perform distributed tracing. .Prerequisites: * {product-title} 4.1 or higher installed. -* {ProductName} {ProductVersion} installed. +* {SMProductName} {SMProductVersion} installed. * Jaeger enabled during the installation. * Bookinfo example application installed. diff --git a/modules/ossm-tutorial-prometheus-querying-metrics.adoc b/modules/ossm-tutorial-prometheus-querying-metrics.adoc index c318ebf0fe96..d971d41958a1 100644 --- a/modules/ossm-tutorial-prometheus-querying-metrics.adoc +++ b/modules/ossm-tutorial-prometheus-querying-metrics.adoc @@ -6,12 +6,12 @@ This PROCEDURE module included in the following assemblies: [id="ossm-tutorial-prometheus-querying-metrics_{context}"] = Querying Prometheus metrics -This tutorial uses {ProductShortName} and the `bookinfo` tutorial to demonstrate how you can query for metrics using Prometheus. +This tutorial uses {SMProductShortName} and the `bookinfo` tutorial to demonstrate how you can query for metrics using Prometheus. .Prerequisites: * {product-title} 3.11 or higher installed. -* {ProductName} {ProductVersion} installed. +* {SMProductName} {SMProductVersion} installed. * `Bookinfo` demonstration application installed. After you have verified the Bookinfo application has deployed, you will need to generate calls to the application before you query for metrics. diff --git a/modules/ossm-understanding-service-mesh.adoc b/modules/ossm-understanding-service-mesh.adoc index 44be4cc405bf..90a4e191da31 100644 --- a/modules/ossm-understanding-service-mesh.adoc +++ b/modules/ossm-understanding-service-mesh.adoc @@ -8,11 +8,11 @@ Module included in the following assemblies: [id="ossm-understanding-service-mesh_{context}"] = Understanding service mesh -A _service mesh_ is the network of microservices that make up applications in a distributed microservice architecture and the interactions between those microservices. When a {ProductShortName} grows in size and complexity, it can become harder to understand and manage. +A _service mesh_ is the network of microservices that make up applications in a distributed microservice architecture and the interactions between those microservices. When a {SMProductShortName} grows in size and complexity, it can become harder to understand and manage. -Based on the open source link:https://istio.io/[Istio] project, {ProductName} adds a transparent layer on existing distributed applications without requiring any changes to the service code. You add {ProductName} support to services by deploying a special sidecar proxy to relevant services in the mesh that intercepts all network communication between microservices. You configure and manage the {ProductShortName} using the control plane features. +Based on the open source link:https://istio.io/[Istio] project, {SMProductName} adds a transparent layer on existing distributed applications without requiring any changes to the service code. You add {SMProductName} support to services by deploying a special sidecar proxy to relevant services in the mesh that intercepts all network communication between microservices. You configure and manage the {SMProductShortName} using the control plane features. -{ProductName} gives you an easy way to create a network of deployed services that provide: +{SMProductName} gives you an easy way to create a network of deployed services that provide: * Discovery * Load balancing @@ -21,7 +21,7 @@ Based on the open source link:https://istio.io/[Istio] project, {ProductName} ad * Metrics * Monitoring -{ProductName} also provides more complex operational functions including: +{SMProductName} also provides more complex operational functions including: * A/B testing * Canary releases diff --git a/modules/ossm-understanding-versions.adoc b/modules/ossm-understanding-versions.adoc index 28a26fc31ccb..e41afcfb3397 100644 --- a/modules/ossm-understanding-versions.adoc +++ b/modules/ossm-understanding-versions.adoc @@ -7,18 +7,18 @@ [id="ossm-versions_{context}"] = Understanding Service Mesh versions -In order to understand what version of {ProductName} you have deployed on your system, you need to understand how each of the component versions is managed. +In order to understand what version of {SMProductName} you have deployed on your system, you need to understand how each of the component versions is managed. -The {ProductName} 2.x Operator supports both v1x and v2x service meshes. +The {SMProductName} 2.x Operator supports both v1x and v2x service meshes. -* *Operator* version - The current Operator version is {ProductVersion}. This version number only indicates the version of the currently installed Operator. This version number is controlled by the intersection of the *Update Channel* and *Approval Strategy* specified in your Operator subscription. The version of the Operator does not determine which version of the `ServiceMeshControlPlane` resource is deployed. +* *Operator* version - The current Operator version is {SMProductVersion}. This version number only indicates the version of the currently installed Operator. This version number is controlled by the intersection of the *Update Channel* and *Approval Strategy* specified in your Operator subscription. The version of the Operator does not determine which version of the `ServiceMeshControlPlane` resource is deployed. + [IMPORTANT] ==== Upgrading to the latest Operator version does not automatically upgrade your control plane to the latest version. ==== + -* *ServiceMeshControlPlane* version - The same Operator supports multiple versions of the service mesh control plane. The service mesh control plane version controls the architecture and configuration settings that are used to install and deploy {ProductName}. To set or change the service mesh control plane version, you must deploy a new control plane. When you create the service mesh control plane you can select the version in one of two ways: +* *ServiceMeshControlPlane* version - The same Operator supports multiple versions of the service mesh control plane. The service mesh control plane version controls the architecture and configuration settings that are used to install and deploy {SMProductName}. To set or change the service mesh control plane version, you must deploy a new control plane. When you create the service mesh control plane you can select the version in one of two ways: ** To configure in the Form View, select the version from the *Control Plane Version* menu. diff --git a/modules/ossm-upgrade-considerations.adoc b/modules/ossm-upgrade-considerations.adoc index 95af68209752..8b9b3fe59552 100644 --- a/modules/ossm-upgrade-considerations.adoc +++ b/modules/ossm-upgrade-considerations.adoc @@ -4,7 +4,7 @@ [id="ossm-upgrade-considerations_{context}"] = Upgrade considerations -The `maistra.io/` label or annotation should not be used on a user-created custom resource, because it indicates that the resource was generated by and should be managed by the {ProductName} Operator. +The `maistra.io/` label or annotation should not be used on a user-created custom resource, because it indicates that the resource was generated by and should be managed by the {SMProductName} Operator. [WARNING] ==== @@ -13,7 +13,7 @@ During the upgrade, the Operator makes changes, including deleting or replacing Before upgrading check for user-created custom resources that include the following labels or annotations: -* `maistra.io/` AND the `app.kubernetes.io/managed-by` label set to `maistra-istio-operator` ({ProductName}) +* `maistra.io/` AND the `app.kubernetes.io/managed-by` label set to `maistra-istio-operator` ({SMProductName}) * `kiali.io/` (Kiali) diff --git a/modules/ossm-upgrading-to-21.adoc b/modules/ossm-upgrading-to-21.adoc index 8d0de4767edc..cd5cffe7fb9b 100644 --- a/modules/ossm-upgrading-to-21.adoc +++ b/modules/ossm-upgrading-to-21.adoc @@ -3,20 +3,20 @@ :_content-type: PROCEDURE [id="ossm-upgrading-to-21_{context}"] -= Upgrading {ProductName} from version 2.0 to version 2.1 += Upgrading {SMProductName} from version 2.0 to version 2.1 -Upgrading from version 2.0 to 2.1 requires manual steps that migrate your workloads and application to a new instance of {ProductName} running the new version. +Upgrading from version 2.0 to 2.1 requires manual steps that migrate your workloads and application to a new instance of {SMProductName} running the new version. [id="ossm-upgrading-upgrade-2-1_{context}"] -== Upgrading to {ProductName} 2.1 +== Upgrading to {SMProductName} 2.1 -To upgrade {ProductName}, you must update the version field of the {ProductName} `ServiceMeshControlPlane` v2 resource. Then, once it's configured and applied, restart the application pods to update each sidecar proxy and its configuration. +To upgrade {SMProductName}, you must update the version field of the {SMProductName} `ServiceMeshControlPlane` v2 resource. Then, once it's configured and applied, restart the application pods to update each sidecar proxy and its configuration. .Prerequisites * You are running {product-title} 4.6 or later. -* You have the {ProductName} version 2.1.0 operator. If the *automatic* upgrade path is enabled, the operator automatically downloads the latest information. However, there are steps you must take to use the features in {ProductName} version 2.1. -* You must upgrade from {ProductName} 2.0 to 2.1. You cannot upgrade `ServiceMeshControlPlane` from 1.1 to 2.1 directly. +* You have the {SMProductName} version 2.1.0 operator. If the *automatic* upgrade path is enabled, the operator automatically downloads the latest information. However, there are steps you must take to use the features in {SMProductName} version 2.1. +* You must upgrade from {SMProductName} 2.0 to 2.1. You cannot upgrade `ServiceMeshControlPlane` from 1.1 to 2.1 directly. .Procedure @@ -77,7 +77,7 @@ This upgrade introduces the following architectural and behavioral changes. .Architecture changes -Mixer has been completely removed in {ProductName} 2.1. Upgrading from a {ProductName} 2.0.x release to 2.1 will be blocked if Mixer is enabled. +Mixer has been completely removed in {SMProductName} 2.1. Upgrading from a {SMProductName} 2.0.x release to 2.1 will be blocked if Mixer is enabled. [id="ossm-upgrading-differences-behavior_{context}"] .Behavioral changes diff --git a/modules/ossm-validating-operators.adoc b/modules/ossm-validating-operators.adoc index bcf1dd820580..46b108c8d24d 100644 --- a/modules/ossm-validating-operators.adoc +++ b/modules/ossm-validating-operators.adoc @@ -6,7 +6,7 @@ //The Operator installation steps include verifying the Operator status in the OpenShift console. -When you install the {ProductName} Operators, OpenShift automatically creates the following objects as part of a successful Operator installation: +When you install the {SMProductName} Operators, OpenShift automatically creates the following objects as part of a successful Operator installation: * config maps * custom resource definitions diff --git a/modules/ossm-validating-smcp.adoc b/modules/ossm-validating-smcp.adoc index 7a30cbcfe51c..27b2b2183380 100644 --- a/modules/ossm-validating-smcp.adoc +++ b/modules/ossm-validating-smcp.adoc @@ -4,7 +4,7 @@ [id="ossm-validating-smcp_{context}"] = Validating the Service Mesh control plane installation -When you create the Service Mesh control plane, the {ProductShortName} Operator uses the parameters that you have specified in the `ServiceMeshControlPlane` resource file to do the following: +When you create the Service Mesh control plane, the {SMProductShortName} Operator uses the parameters that you have specified in the `ServiceMeshControlPlane` resource file to do the following: * Creates the Istio components and deploys the following pods: ** `istiod` @@ -16,14 +16,14 @@ When you create the Service Mesh control plane, the {ProductShortName} Operator + [NOTE] ==== -You view the Kiali components under the Kiali Operator, not the {ProductShortName} Operator. +You view the Kiali components under the Kiali Operator, not the {SMProductShortName} Operator. ==== + * Calls the {JaegerName} Operator to create {JaegerShortName} components based on configuration in either the SMCP or the Jaeger custom resource. + [NOTE] ==== -You view the Jaeger components under the {JaegerName} Operator and the Elasticsearch components under the Elasticsearch Operator, not the {ProductShortName} Operator. +You view the Jaeger components under the {JaegerName} Operator and the Elasticsearch components under the Elasticsearch Operator, not the {SMProductShortName} Operator. ==== + .From the {product-title} console @@ -32,7 +32,7 @@ You can verify the Service Mesh control plane installation in the {product-title . Navigate to *Operators* -> *Installed Operators*. . Select the `` namespace. -. Select the {ProductName} Operator. +. Select the {SMProductName} Operator. . Click the *Istio Service Mesh Control Plane* tab. . Click the name of your control plane, for example `basic`. . To view the resources created by the deployment, click the *Resources* tab. You can use the filter to narrow your view, for example, to check that all the *Pods* have a status of `running`. diff --git a/modules/ossm-vs-istio-1x.adoc b/modules/ossm-vs-istio-1x.adoc index 8fcc58e09e0f..ebfeddd03136 100644 --- a/modules/ossm-vs-istio-1x.adoc +++ b/modules/ossm-vs-istio-1x.adoc @@ -4,21 +4,21 @@ Module included in the following assemblies: //// [id="ossm-vs-istio_{context}"] -= Differences between Istio and {ProductName} += Differences between Istio and {SMProductName} -An installation of {ProductName} differs from an installation of Istio in multiple ways. The modifications to {ProductName} are sometimes necessary to resolve issues, provide additional features, or to handle differences when deploying on {product-title}. +An installation of {SMProductName} differs from an installation of Istio in multiple ways. The modifications to {SMProductName} are sometimes necessary to resolve issues, provide additional features, or to handle differences when deploying on {product-title}. [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 {SMProductName} is oc.  {SMProductName}  does not support istioctl. [id="ossm-automatic-injection_{context}"] == Automatic injection The upstream Istio community installation automatically injects the sidecar into pods within the projects you have labeled. -{ProductName} does not automatically inject the sidecar to any pods, but requires you to opt in to injection using an annotation without labeling projects. This method requires fewer privileges and does not conflict with other OpenShift capabilities such as builder pods. To enable automatic injection you specify the `sidecar.istio.io/inject` annotation as described in the Automatic sidecar injection section. +{SMProductName} does not automatically inject the sidecar to any pods, but requires you to opt in to injection using an annotation without labeling projects. This method requires fewer privileges and does not conflict with other OpenShift capabilities such as builder pods. To enable automatic injection you specify the `sidecar.istio.io/inject` annotation as described in the Automatic sidecar injection section. [id="ossm-rbac_{context}"] == Istio Role Based Access Control features @@ -27,7 +27,7 @@ Istio Role Based Access Control (RBAC) provides a mechanism you can use to contr The upstream Istio community installation includes options to perform exact header matches, match wildcards in headers, or check for a header containing a specific prefix or suffix. -{ProductName} extends the ability to match request headers by using a regular expression. Specify a property key of `request.regex.headers` with a regular expression. +{SMProductName} extends the ability to match request headers by using a regular expression. Specify a property key of `request.regex.headers` with a regular expression. .Upstream Istio community matching request headers example [source,yaml] @@ -44,7 +44,7 @@ spec: request.headers[
]: "value" ---- -.{ProductName} matching request headers by using regular expressions +.{SMProductName} matching request headers by using regular expressions [source,yaml] ---- apiVersion: "rbac.istio.io/v1alpha1" @@ -63,7 +63,7 @@ spec: [id="ossm-openssl_{context}"] == OpenSSL -{ProductName} replaces BoringSSL with OpenSSL. OpenSSL is a software library that contains an open source implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. The {ProductName} Proxy binary dynamically links the OpenSSL libraries (libssl and libcrypto) from the underlying Red Hat Enterprise Linux operating system. +{SMProductName} replaces BoringSSL with OpenSSL. OpenSSL is a software library that contains an open source implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. The {SMProductName} Proxy binary dynamically links the OpenSSL libraries (libssl and libcrypto) from the underlying Red Hat Enterprise Linux operating system. [id="ossm-component-modifications_{context}"] == Component modifications @@ -77,28 +77,28 @@ spec: [id="ossm-envoy-sds-ca_{context}"] == Envoy, Secret Discovery Service, and certificates -* {ProductName} does not support QUIC-based services. -* Deployment of TLS certificates using the Secret Discovery Service (SDS) functionality of Istio is not currently supported in {ProductName}. The Istio implementation depends on a nodeagent container that uses hostPath mounts. +* {SMProductName} does not support QUIC-based services. +* Deployment of TLS certificates using the Secret Discovery Service (SDS) functionality of Istio is not currently supported in {SMProductName}. The Istio implementation depends on a nodeagent container that uses hostPath mounts. [id="ossm-cni_{context}"] == Istio Container Network Interface (CNI) plug-in -{ProductName} includes CNI plug-in, which provides you with an alternate way to configure application pod networking. The CNI plug-in replaces the `init-container` network configuration eliminating the need to grant service accounts and projects access to Security Context Constraints (SCCs) with elevated privileges. +{SMProductName} includes CNI plug-in, which provides you with an alternate way to configure application pod networking. The CNI plug-in replaces the `init-container` network configuration eliminating the need to grant service accounts and projects access to Security Context Constraints (SCCs) with elevated privileges. [id="ossm-routes-gateways_{context}"] == Routes for Istio Gateways -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. -A {ProductName} control plane component called Istio OpenShift Routing (IOR) synchronizes the gateway route. For more information, see Automatic route creation. +A {SMProductName} control plane component called Istio OpenShift Routing (IOR) synchronizes the gateway route. For more information, see Automatic route creation. [id="ossm-catch-all-domains_{context}"] === Catch-all domains -Catch-all domains ("\*") are not supported. If one is found in the Gateway definition, {ProductName} _will_ create the route, but will rely on OpenShift to create a default hostname. This means that the newly created route will __not__ be a catch all ("*") route, instead it will have a hostname in the form `[-].`. See the OpenShift documentation for more information about how default hostnames work and how a cluster administrator can customize it. +Catch-all domains ("\*") are not supported. If one is found in the Gateway definition, {SMProductName} _will_ create the route, but will rely on OpenShift to create a default hostname. This means that the newly created route will __not__ be a catch all ("*") route, instead it will have a hostname in the form `[-].`. See the OpenShift documentation for more information about how default hostnames work and how a cluster administrator can customize it. [id="ossm-subdomains_{context}"] === Subdomains -Subdomains (e.g.: "*.domain.com") are supported. However this ability doesn't come enabled by default in {product-title}. This means that {ProductName} _will_ create the route with the subdomain, but it will only be in effect if {product-title} is configured to enable it. +Subdomains (e.g.: "*.domain.com") are supported. However this ability doesn't come enabled by default in {product-title}. This means that {SMProductName} _will_ create the route with the subdomain, but it will only be in effect if {product-title} is configured to enable it. [id="ossm-tls_{context}"] === Transport layer security diff --git a/modules/ossm-vs-istio.adoc b/modules/ossm-vs-istio.adoc index d8e880d737c8..0ec0a13e6861 100644 --- a/modules/ossm-vs-istio.adoc +++ b/modules/ossm-vs-istio.adoc @@ -4,22 +4,22 @@ Module included in the following assemblies: //// [id="ossm-vs-istio_{context}"] -= Differences between Istio and {ProductName} += Differences between Istio and {SMProductName} -The following features are different in {ProductShortName} and Istio. +The following features are different in {SMProductShortName} and Istio. [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 {SMProductName} is `oc`.  {SMProductName} does not support `istioctl`. [id="ossm-installation-upgrade_{context}"] == Installation and upgrades -{ProductName} does not support Istio installation profiles. +{SMProductName} does not support Istio installation profiles. -{ProductName} does not support canary upgrades of the service mesh. +{SMProductName} does not support canary upgrades of the service mesh. [id="ossm-automatic-injection_{context}"] @@ -27,7 +27,7 @@ The command line tool for {ProductName} is `oc`.  {ProductName} does not suppo The upstream Istio community installation automatically injects the sidecar into pods within the projects you have labeled. -{ProductName} does not automatically inject the sidecar to any pods, but requires you to opt in to injection using an annotation without labeling projects. This method requires fewer privileges and does not conflict with other OpenShift capabilities such as builder pods. To enable automatic injection you specify the `sidecar.istio.io/inject` annotation as described in the Automatic sidecar injection section. +{SMProductName} does not automatically inject the sidecar to any pods, but requires you to opt in to injection using an annotation without labeling projects. This method requires fewer privileges and does not conflict with other OpenShift capabilities such as builder pods. To enable automatic injection you specify the `sidecar.istio.io/inject` annotation as described in the Automatic sidecar injection section. [id="ossm-rbac_{context}"] == Istio Role Based Access Control features @@ -36,7 +36,7 @@ Istio Role Based Access Control (RBAC) provides a mechanism you can use to contr The upstream Istio community installation includes options to perform exact header matches, match wildcards in headers, or check for a header containing a specific prefix or suffix. -{ProductName} extends the ability to match request headers by using a regular expression. Specify a property key of `request.regex.headers` with a regular expression. +{SMProductName} extends the ability to match request headers by using a regular expression. Specify a property key of `request.regex.headers` with a regular expression. .Upstream Istio community matching request headers example [source,yaml] @@ -60,13 +60,13 @@ spec: [id="ossm-openssl_{context}"] == OpenSSL -{ProductName} replaces BoringSSL with OpenSSL. OpenSSL is a software library that contains an open source implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. The {ProductName} Proxy binary dynamically links the OpenSSL libraries (libssl and libcrypto) from the underlying Red Hat Enterprise Linux operating system. +{SMProductName} replaces BoringSSL with OpenSSL. OpenSSL is a software library that contains an open source implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. The {SMProductName} Proxy binary dynamically links the OpenSSL libraries (libssl and libcrypto) from the underlying Red Hat Enterprise Linux operating system. [id="ossm-external-workloads_{context}"] == External workloads -{ProductName} does not support external workloads (virtual machines). +{SMProductName} does not support external workloads (virtual machines). [id="ossm-component-modifications_{context}"] == Component modifications @@ -80,27 +80,27 @@ spec: [id="ossm-envoy-services_{context}"] == Envoy services -{ProductName} does not support QUIC-based services. +{SMProductName} does not support QUIC-based services. [id="ossm-cni_{context}"] == Istio Container Network Interface (CNI) plug-in -{ProductName} includes CNI plug-in, which provides you with an alternate way to configure application pod networking. The CNI plug-in replaces the `init-container` network configuration eliminating the need to grant service accounts and projects access to security context constraints (SCCs) with elevated privileges. +{SMProductName} includes CNI plug-in, which provides you with an alternate way to configure application pod networking. The CNI plug-in replaces the `init-container` network configuration eliminating the need to grant service accounts and projects access to security context constraints (SCCs) with elevated privileges. [id="ossm-routes-gateways_{context}"] == Routes for Istio Gateways -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. -A {ProductName} control plane component called Istio OpenShift Routing (IOR) synchronizes the gateway route. For more information, see Automatic route creation. +A {SMProductName} control plane component called Istio OpenShift Routing (IOR) synchronizes the gateway route. For more information, see Automatic route creation. [id="ossm-catch-all-domains_{context}"] === Catch-all domains -Catch-all domains ("\*") are not supported. If one is found in the Gateway definition, {ProductName} _will_ create the route, but will rely on OpenShift to create a default hostname. This means that the newly created route will __not__ be a catch all ("*") route, instead it will have a hostname in the form `[-].`. See the {product-title} documentation for more information about how default hostnames work and how a `cluster-admin` can customize it. If you use {product-dedicated}, refer to the {product-dedicated} the `dedicated-admin` role. +Catch-all domains ("\*") are not supported. If one is found in the Gateway definition, {SMProductName} _will_ create the route, but will rely on OpenShift to create a default hostname. This means that the newly created route will __not__ be a catch all ("*") route, instead it will have a hostname in the form `[-].`. See the {product-title} documentation for more information about how default hostnames work and how a `cluster-admin` can customize it. If you use {product-dedicated}, refer to the {product-dedicated} the `dedicated-admin` role. [id="ossm-subdomains_{context}"] === Subdomains -Subdomains (e.g.: "*.domain.com") are supported. However this ability doesn't come enabled by default in {product-title}. This means that {ProductName} _will_ create the route with the subdomain, but it will only be in effect if {product-title} is configured to enable it. +Subdomains (e.g.: "*.domain.com") are supported. However this ability doesn't come enabled by default in {product-title}. This means that {SMProductName} _will_ create the route with the subdomain, but it will only be in effect if {product-title} is configured to enable it. [id="ossm-tls_{context}"] === Transport layer security @@ -110,4 +110,4 @@ Transport Layer Security (TLS) is supported. This means that, if the Gateway con [id="ossm-wasm_{context}"] === WebAssembly Extensions -{ProductName} 2.0 introduces WebAssembly extensions to Envoy Proxy as a link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview]. Note that WASM extensions are not included in the proxy binary and that WASM filters from the upstream Istio community are not supported in {ProductName} 2.0. +{SMProductName} 2.0 introduces WebAssembly extensions to Envoy Proxy as a link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview]. Note that WASM extensions are not included in the proxy binary and that WASM filters from the upstream Istio community are not supported in {SMProductName} 2.0. diff --git a/post_installation_configuration/cluster-tasks.adoc b/post_installation_configuration/cluster-tasks.adoc index 3f7d4a6397f0..2b9c31603da3 100644 --- a/post_installation_configuration/cluster-tasks.adoc +++ b/post_installation_configuration/cluster-tasks.adoc @@ -3,7 +3,6 @@ [id="post-install-cluster-tasks"] = Post-installation cluster tasks include::_attributes/common-attributes.adoc[] -include::_attributes/ossm-document-attributes.adoc[] toc::[] diff --git a/post_installation_configuration/network-configuration.adoc b/post_installation_configuration/network-configuration.adoc index 4465ed66f114..125cfe8af29f 100644 --- a/post_installation_configuration/network-configuration.adoc +++ b/post_installation_configuration/network-configuration.adoc @@ -3,7 +3,6 @@ [id="post-install-network-configuration"] = Post-installation network configuration include::_attributes/common-attributes.adoc[] -include::_attributes/ossm-document-attributes.adoc[] toc::[] @@ -106,4 +105,4 @@ You can configure some aspects of an {product-title} on {rh-openstack-first} clu include::modules/installation-osp-configuring-api-floating-ip.adoc[leveloffset=+2] include::modules/installation-osp-kuryr-port-pools.adoc[leveloffset=+2] include::modules/installation-osp-kuryr-settings-active.adoc[leveloffset=+2] -include::modules/nw-osp-enabling-ovs-offload.adoc[leveloffset=+2] \ No newline at end of file +include::modules/nw-osp-enabling-ovs-offload.adoc[leveloffset=+2] diff --git a/scalability_and_performance/recommended-host-practices.adoc b/scalability_and_performance/recommended-host-practices.adoc index d889a3b0169c..ef2b4afcd208 100644 --- a/scalability_and_performance/recommended-host-practices.adoc +++ b/scalability_and_performance/recommended-host-practices.adoc @@ -2,7 +2,6 @@ [id="recommended-host-practices"] = Recommended host practices include::_attributes/common-attributes.adoc[] -include::_attributes/ossm-document-attributes.adoc[] :context: recommended-host-practices toc::[] diff --git a/serverless/admin_guide/serverless-ossm-setup.adoc b/serverless/admin_guide/serverless-ossm-setup.adoc index 1ef733f76b0f..823a43669d10 100644 --- a/serverless/admin_guide/serverless-ossm-setup.adoc +++ b/serverless/admin_guide/serverless-ossm-setup.adoc @@ -1,6 +1,5 @@ :_content-type: ASSEMBLY include::_attributes/serverless-document-attributes.adoc[] -include::_attributes/ossm-document-attributes.adoc[] include::_attributes/common-attributes.adoc[] [id="serverless-ossm-setup"] = Integrating {ProductShortName} with {ServerlessProductName} diff --git a/serverless/security/serverless-custom-domains.adoc b/serverless/security/serverless-custom-domains.adoc index e77087473644..ed1236d76d88 100644 --- a/serverless/security/serverless-custom-domains.adoc +++ b/serverless/security/serverless-custom-domains.adoc @@ -3,7 +3,6 @@ = Configuring a custom domain for a Knative service include::_attributes/common-attributes.adoc[] include::_attributes/serverless-document-attributes.adoc[] -include::_attributes/ossm-document-attributes.adoc[] :context: serverless-custom-domains toc::[] diff --git a/serverless/security/serverless-custom-tls-cert-domain-mapping.adoc b/serverless/security/serverless-custom-tls-cert-domain-mapping.adoc index 92f9029a0e9f..24ab9d07f464 100644 --- a/serverless/security/serverless-custom-tls-cert-domain-mapping.adoc +++ b/serverless/security/serverless-custom-tls-cert-domain-mapping.adoc @@ -3,7 +3,6 @@ = Using a custom TLS certificate for domain mapping include::_attributes/common-attributes.adoc[] include::_attributes/serverless-document-attributes.adoc[] -include::_attributes/ossm-document-attributes.adoc[] :context: serverless-custom-tls-cert-domain-mapping toc::[] diff --git a/serverless/security/serverless-ossm-with-kourier-jwt.adoc b/serverless/security/serverless-ossm-with-kourier-jwt.adoc index 112251a69247..f0755b4e2f79 100644 --- a/serverless/security/serverless-ossm-with-kourier-jwt.adoc +++ b/serverless/security/serverless-ossm-with-kourier-jwt.adoc @@ -3,7 +3,6 @@ = Configuring JSON Web Token authentication for Knative services include::_attributes/common-attributes.adoc[] include::_attributes/serverless-document-attributes.adoc[] -include::_attributes/ossm-document-attributes.adoc[] :context: serverless-ossm-with-kourier-jwt toc::[] diff --git a/service_mesh/v1x/installing-ossm.adoc b/service_mesh/v1x/installing-ossm.adoc index 5120bafb6cad..1189c5b03bf2 100644 --- a/service_mesh/v1x/installing-ossm.adoc +++ b/service_mesh/v1x/installing-ossm.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="installing-ossm-v1x"] = Installing Service Mesh -include::_attributes/ossm-document-attributes-1x.adoc[] +include::_attributes/common-attributes.adoc[] :context: installing-ossm-v1x toc::[] -Installing the {ProductShortName} involves installing the OpenShift Elasticsearch, Jaeger, Kiali and {ProductShortName} Operators, creating and managing a `ServiceMeshControlPlane` resource to deploy the control plane, and creating a `ServiceMeshMemberRoll` resource to specify the namespaces associated with the {ProductShortName}. +Installing the {SMProductShortName} involves installing the OpenShift Elasticsearch, Jaeger, Kiali and {SMProductShortName} Operators, creating and managing a `ServiceMeshControlPlane` resource to deploy the control plane, and creating a `ServiceMeshMemberRoll` resource to specify the namespaces associated with the {SMProductShortName}. [NOTE] ==== @@ -15,21 +15,21 @@ Mixer's policy enforcement is disabled by default. You must enable it to run pol [NOTE] ==== -Multi-tenant control plane installations are the default configuration starting with {ProductName} 1.0. +Multi-tenant control plane installations are the default configuration starting with {SMProductName} 1.0. ==== [NOTE] ==== -The {ProductShortName} documentation uses `istio-system` as the example project, but you can deploy the service mesh to any project. +The {SMProductShortName} documentation uses `istio-system` as the example project, but you can deploy the service mesh to any project. ==== == Prerequisites -* Follow the xref:../../service_mesh/v1x/preparing-ossm-installation.adoc#preparing-ossm-installation-v1x[Preparing to install {ProductName}] process. +* Follow the xref:../../service_mesh/v1x/preparing-ossm-installation.adoc#preparing-ossm-installation-v1x[Preparing to install {SMProductName}] process. * An account with the `cluster-admin` role. -The {ProductShortName} installation process uses the link:https://operatorhub.io/[OperatorHub] to install the `ServiceMeshControlPlane` custom resource definition within the `openshift-operators` project. The {ProductName} defines and monitors the `ServiceMeshControlPlane` related to the deployment, update, and deletion of the control plane. +The {SMProductShortName} installation process uses the link:https://operatorhub.io/[OperatorHub] to install the `ServiceMeshControlPlane` custom resource definition within the `openshift-operators` project. The {SMProductName} defines and monitors the `ServiceMeshControlPlane` related to the deployment, update, and deletion of the control plane. -Starting with {ProductName} {ProductVersion}, you must install the OpenShift Elasticsearch Operator, the Jaeger Operator, and the Kiali Operator before the {ProductName} Operator can install the control plane. +Starting with {SMProductName} {SMProductVersion1x}, you must install the OpenShift Elasticsearch Operator, the Jaeger Operator, and the Kiali Operator before the {SMProductName} Operator can install the control plane. include::modules/jaeger-install-elasticsearch.adoc[leveloffset=+1] @@ -41,7 +41,7 @@ include::modules/ossm-install-ossm-operator.adoc[leveloffset=+1] include::modules/ossm-control-plane-deploy-1x.adoc[leveloffset=+1] -For a multitenant installation, {ProductName} supports multiple independent control planes within the cluster. You can create reusable configurations with `ServiceMeshControlPlane` templates. For more information, see xref:../../service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc#ossm-control-plane-templates-1x_deploying-applications-ossm-v1x[Creating control plane templates]. +For a multitenant installation, {SMProductName} supports multiple independent control planes within the cluster. You can create reusable configurations with `ServiceMeshControlPlane` templates. For more information, see xref:../../service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc#ossm-control-plane-templates-1x_deploying-applications-ossm-v1x[Creating control plane templates]. include::modules/ossm-member-roll-create.adoc[leveloffset=+1] @@ -58,4 +58,4 @@ include::modules/ossm-update-app-sidecar.adoc[leveloffset=+2] == Next steps -* xref:../../service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc#deploying-applications-ossm-v1x[Prepare to deploy applications] on {ProductName}. +* xref:../../service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc#deploying-applications-ossm-v1x[Prepare to deploy applications] on {SMProductName}. diff --git a/service_mesh/v1x/ossm-architecture.adoc b/service_mesh/v1x/ossm-architecture.adoc index 3a693d507fed..031aedad729f 100644 --- a/service_mesh/v1x/ossm-architecture.adoc +++ b/service_mesh/v1x/ossm-architecture.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="ossm-architecture-v1x"] = Understanding Service Mesh -include::_attributes/ossm-document-attributes-1x.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-architecture-v1x toc::[] -{ProductName} provides a platform for behavioral insight and operational control over your networked microservices in a service mesh. With {ProductName}, you can connect, secure, and monitor microservices in your {product-title} environment. +{SMProductName} provides a platform for behavioral insight and operational control over your networked microservices in a service mesh. With {SMProductName}, you can connect, secure, and monitor microservices in your {product-title} environment. include::modules/ossm-understanding-service-mesh.adoc[leveloffset=+1] @@ -45,4 +45,4 @@ include::modules/jaeger-features.adoc[leveloffset=+2] == Next steps -* xref:../../service_mesh/v1x/preparing-ossm-installation.adoc#preparing-ossm-installation-v1x[Prepare to install {ProductName}] in your {product-title} environment. +* xref:../../service_mesh/v1x/preparing-ossm-installation.adoc#preparing-ossm-installation-v1x[Prepare to install {SMProductName}] in your {product-title} environment. diff --git a/service_mesh/v1x/ossm-config.adoc b/service_mesh/v1x/ossm-config.adoc index 4efa751a00d6..89159c87f52f 100644 --- a/service_mesh/v1x/ossm-config.adoc +++ b/service_mesh/v1x/ossm-config.adoc @@ -1,7 +1,7 @@ :_content-type: ASSEMBLY [id="ossm-config-v1x"] = Configuring Service Mesh -include::_attributes/ossm-document-attributes-1x.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-config-v1x toc::[] diff --git a/service_mesh/v1x/ossm-custom-resources.adoc b/service_mesh/v1x/ossm-custom-resources.adoc index 41f5606dffed..23dd29cdadc6 100644 --- a/service_mesh/v1x/ossm-custom-resources.adoc +++ b/service_mesh/v1x/ossm-custom-resources.adoc @@ -1,16 +1,16 @@ :_content-type: ASSEMBLY [id="ossm-custom-resources-v1x"] = Custom resources -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-controler-items-v1x toc::[] -You can customize your {ProductName} by modifying the default {ProductShortName} custom resource or by creating a new custom resource. +You can customize your {SMProductName} by modifying the default {SMProductShortName} custom resource or by creating a new custom resource. == Prerequisites * An account with the `cluster-admin` role. -* Completed the xref:../../service_mesh/v1x/preparing-ossm-installation.adoc#preparing-ossm-installation-v1x[Preparing to install {ProductName}] process. +* Completed the xref:../../service_mesh/v1x/preparing-ossm-installation.adoc#preparing-ossm-installation-v1x[Preparing to install {SMProductName}] process. * Have installed the operators. include::modules/ossm-cr-example-1x.adoc[leveloffset=+1] diff --git a/service_mesh/v1x/ossm-observability.adoc b/service_mesh/v1x/ossm-observability.adoc index db946a93bc95..c31c1a971619 100644 --- a/service_mesh/v1x/ossm-observability.adoc +++ b/service_mesh/v1x/ossm-observability.adoc @@ -1,7 +1,7 @@ :_content-type: ASSEMBLY [id="ossm-observability-v1x"] = Data visualization and observability -include::_attributes/ossm-document-attributes-1x.adoc[] +include::_attributes/common-attributes.adoc[] :context: observability-v1x toc::[] @@ -10,7 +10,7 @@ You can view your application's topology, health and metrics in the Kiali consol .Before you begin -You can observe the data flow through your application if you have an application installed. If you don't have your own application installed, you can see how observability works in {ProductName} by installing the xref:../../service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc#ossm-tutorial-bookinfo-overview_deploying-applications-ossm-v1x[Bookinfo sample application]. +You can observe the data flow through your application if you have an application installed. If you don't have your own application installed, you can see how observability works in {SMProductName} by installing the xref:../../service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc#ossm-tutorial-bookinfo-overview_deploying-applications-ossm-v1x[Bookinfo sample application]. include::modules/ossm-observability-access.adoc[leveloffset=+1] diff --git a/service_mesh/v1x/ossm-security.adoc b/service_mesh/v1x/ossm-security.adoc index d8d8d522c0be..75edac3838dc 100644 --- a/service_mesh/v1x/ossm-security.adoc +++ b/service_mesh/v1x/ossm-security.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="ossm-security-v1x"] = Customizing security in a Service Mesh -include::_attributes/ossm-document-attributes-1x.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-security-v1x toc::[] -If your service mesh application is constructed with a complex array of microservices, you can use {ProductName} to customize the security of the communication between those services. The infrastructure of {product-title} along with the traffic management features of {ProductShortName} can help you manage the complexity of your applications and provide service and identity security for microservices. +If your service mesh application is constructed with a complex array of microservices, you can use {SMProductName} to customize the security of the communication between those services. The infrastructure of {product-title} along with the traffic management features of {SMProductShortName} can help you manage the complexity of your applications and provide service and identity security for microservices. include::modules/ossm-security-mtls-1x.adoc[leveloffset=+1] diff --git a/service_mesh/v1x/ossm-traffic-manage.adoc b/service_mesh/v1x/ossm-traffic-manage.adoc index c08b87b415b1..33dda099579a 100644 --- a/service_mesh/v1x/ossm-traffic-manage.adoc +++ b/service_mesh/v1x/ossm-traffic-manage.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="ossm-routing-traffic-v1x"] = Traffic management -include::_attributes/ossm-document-attributes-1x.adoc[] +include::_attributes/common-attributes.adoc[] :context: routing-traffic-v1x toc::[] -You can control the flow of traffic and API calls between services in {ProductName}. For example, some services in your service mesh may need to communicate within the mesh and others may need to be hidden. Manage the traffic to hide specific backend services, expose services, create testing or versioning deployments, or add a security layer on a set of services. +You can control the flow of traffic and API calls between services in {SMProductName}. For example, some services in your service mesh may need to communicate within the mesh and others may need to be hidden. Manage the traffic to hide specific backend services, expose services, create testing or versioning deployments, or add a security layer on a set of services. This guide references the Bookinfo sample application to provide examples of routing in an example application. Install the xref:../../service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc#ossm-tutorial-bookinfo-overview_deploying-applications-ossm-v1x[Bookinfo application] to learn how these routing examples work. diff --git a/service_mesh/v1x/ossm-vs-community.adoc b/service_mesh/v1x/ossm-vs-community.adoc index 1f095f2a73aa..5aa870577de4 100644 --- a/service_mesh/v1x/ossm-vs-community.adoc +++ b/service_mesh/v1x/ossm-vs-community.adoc @@ -1,14 +1,14 @@ :_content-type: ASSEMBLY [id="ossm-vs-community-v1x"] = Service Mesh and Istio differences -include::_attributes/ossm-document-attributes-1x.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-vs-istio-v1x toc::[] -An installation of {ProductName} differs from upstream Istio community installations in multiple ways. The modifications to {ProductName} are sometimes necessary to resolve issues, provide additional features, or to handle differences when deploying on {product-title}. +An installation of {SMProductName} differs from upstream Istio community installations in multiple ways. The modifications to {SMProductName} are sometimes necessary to resolve issues, provide additional features, or to handle differences when deploying on {product-title}. -The current release of {ProductName} differs from the current upstream Istio community release in the following ways: +The current release of {SMProductName} differs from the current upstream Istio community release in the following ways: // The following include statements pull in the module files that comprise the assembly. diff --git a/service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc b/service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc index fc35e6d7a65a..faad1b329018 100644 --- a/service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc +++ b/service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc @@ -1,18 +1,18 @@ :_content-type: ASSEMBLY [id="deploying-applications-ossm-v1x"] = Deploying applications on Service Mesh -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: deploying-applications-ossm-v1x toc::[] -When you deploy an application into the {ProductShortName}, there are several differences between the behavior of applications in the upstream community version of Istio and the behavior of applications within a {ProductName} installation. +When you deploy an application into the {SMProductShortName}, there are several differences between the behavior of applications in the upstream community version of Istio and the behavior of applications within a {SMProductName} installation. == Prerequisites -* Review xref:../../service_mesh/v1x/ossm-vs-community.adoc#ossm-vs-community-v1x[Comparing {ProductName} and upstream Istio community installations] +* Review xref:../../service_mesh/v1x/ossm-vs-community.adoc#ossm-vs-community-v1x[Comparing {SMProductName} and upstream Istio community installations] -* Review xref:../../service_mesh/v1x/installing-ossm.adoc#installing-ossm-v1x[Installing {ProductName}] +* Review xref:../../service_mesh/v1x/installing-ossm.adoc#installing-ossm-v1x[Installing {SMProductName}] include::modules/ossm-control-plane-templates-1x.adoc[leveloffset=+1] diff --git a/service_mesh/v1x/preparing-ossm-installation.adoc b/service_mesh/v1x/preparing-ossm-installation.adoc index de4b32248915..4ffdacc60d9d 100644 --- a/service_mesh/v1x/preparing-ossm-installation.adoc +++ b/service_mesh/v1x/preparing-ossm-installation.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="preparing-ossm-installation-v1x"] = Preparing to install Service Mesh -include::_attributes/ossm-document-attributes-1x.adoc[] +include::_attributes/common-attributes.adoc[] :context: preparing-ossm-installation-v1x toc::[] -Before you can install {ProductName}, review the installation activities, ensure that you meet the prerequisites: +Before you can install {SMProductName}, review the installation activities, ensure that you meet the prerequisites: == Prerequisites @@ -20,7 +20,7 @@ Before you can install {ProductName}, review the installation activities, ensure + [NOTE] ==== -If you are installing {ProductName} on a xref:../../installing/installing-preparing.adoc#supported-installation-methods-for-different-platforms[restricted network], follow the instructions for your chosen {product-title} infrastructure. +If you are installing {SMProductName} on a xref:../../installing/installing-preparing.adoc#supported-installation-methods-for-different-platforms[restricted network], follow the instructions for your chosen {product-title} infrastructure. ==== + * Install the version of the {product-title} command line utility (the `oc` client tool) that matches your {product-title} version and add it to your path. @@ -37,4 +37,4 @@ See xref:../../logging/config/cluster-logging-log-store.adoc[Configuring the log == Next steps -* xref:../../service_mesh/v1x/installing-ossm.adoc#installing-ossm-v1x[Install {ProductName}] in your {product-title} environment. +* xref:../../service_mesh/v1x/installing-ossm.adoc#installing-ossm-v1x[Install {SMProductName}] in your {product-title} environment. diff --git a/service_mesh/v1x/removing-ossm.adoc b/service_mesh/v1x/removing-ossm.adoc index ec6b42adb1de..4a26caa559d6 100644 --- a/service_mesh/v1x/removing-ossm.adoc +++ b/service_mesh/v1x/removing-ossm.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="removing-ossm-v1x"] = Removing Service Mesh -include::_attributes/ossm-document-attributes-1x.adoc[] +include::_attributes/common-attributes.adoc[] :context: removing-ossm-v1x toc::[] -To remove {ProductName} from an existing {product-title} instance, remove the control plane before removing the operators. +To remove {SMProductName} from an existing {product-title} instance, remove the control plane before removing the operators. include::modules/ossm-control-plane-remove.adoc[leveloffset=+1] diff --git a/service_mesh/v1x/servicemesh-release-notes.adoc b/service_mesh/v1x/servicemesh-release-notes.adoc index 2546d6b6bf31..5aa85a3ca3e5 100644 --- a/service_mesh/v1x/servicemesh-release-notes.adoc +++ b/service_mesh/v1x/servicemesh-release-notes.adoc @@ -1,7 +1,7 @@ :_content-type: ASSEMBLY [id="service-mesh-release-notes-v1x"] = Service Mesh Release Notes -include::_attributes/ossm-document-attributes-1x.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-release-notes-v1x toc::[] @@ -22,10 +22,10 @@ information about your cluster to Red Hat Support. The `must-gather` tool enables you to collect diagnostic information about your {product-title} cluster, including virtual machines and other data related to -{ProductName}. +{SMProductName}. For prompt support, supply diagnostic information for both {product-title} -and {ProductName}. +and {SMProductName}. include::modules/about-must-gather.adoc[leveloffset=+2] diff --git a/service_mesh/v1x/threescale-adapter.adoc b/service_mesh/v1x/threescale-adapter.adoc index fd9f100862c5..dff6a27039e8 100644 --- a/service_mesh/v1x/threescale-adapter.adoc +++ b/service_mesh/v1x/threescale-adapter.adoc @@ -1,13 +1,13 @@ :_content-type: ASSEMBLY [id="threescale-adapter-v1x"] = Using the 3scale Istio adapter -include::_attributes/ossm-document-attributes-1x.adoc[] +include::_attributes/common-attributes.adoc[] :context: threescale-adapter-v1x toc::[] -The 3scale Istio Adapter is an optional adapter that allows you to label a service running within the {ProductName} and integrate that service with the 3scale API Management solution. -It is not required for {ProductName}. +The 3scale Istio Adapter is an optional adapter that allows you to label a service running within the {SMProductName} and integrate that service with the 3scale API Management solution. +It is not required for {SMProductName}. include::modules/ossm-threescale-integrate-1x.adoc[leveloffset=+1] diff --git a/service_mesh/v2x/installing-ossm.adoc b/service_mesh/v2x/installing-ossm.adoc index a2b7a933c79d..23b7b726d0f0 100644 --- a/service_mesh/v2x/installing-ossm.adoc +++ b/service_mesh/v2x/installing-ossm.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="installing-ossm"] = Installing the Operators -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: installing-ossm toc::[] -To install {ProductName}, first install the required Operators on {product-title} and then create a `ServiceMeshControlPlane` resource to deploy the control plane. +To install {SMProductName}, first install the required Operators on {product-title} and then create a `ServiceMeshControlPlane` resource to deploy the control plane. [NOTE] ==== @@ -14,10 +14,10 @@ This basic installation is configured based on the default OpenShift settings an ==== .Prerequisites -* Read the xref:../../service_mesh/v2x/preparing-ossm-installation.adoc#preparing-ossm-installation[Preparing to install {ProductName}] process. +* Read the xref:../../service_mesh/v2x/preparing-ossm-installation.adoc#preparing-ossm-installation[Preparing to install {SMProductName}] process. * An account with the `cluster-admin` role. If you use {product-dedicated}, you must have an account with the `dedicated-admin` role. -The following steps show how to install a basic instance of {ProductName} on {product-title}. +The following steps show how to install a basic instance of {SMProductName} on {product-title}. include::modules/ossm-installation-activities.adoc[leveloffset=+1] @@ -30,4 +30,4 @@ include::modules/ossm-install-ossm-operator.adoc[leveloffset=+1] == Next steps -Create a `ServiceMeshControlPlane` resource to configure the components of {ProductShortName}. For more information, see xref:../../service_mesh/v2x/ossm-create-smcp.adoc#ossm-create-smcp[Creating the ServiceMeshControlPlane]. +Create a `ServiceMeshControlPlane` resource to configure the components of {SMProductShortName}. For more information, see xref:../../service_mesh/v2x/ossm-create-smcp.adoc#ossm-create-smcp[Creating the ServiceMeshControlPlane]. diff --git a/service_mesh/v2x/ossm-about.adoc b/service_mesh/v2x/ossm-about.adoc index f5638e6bab21..6e2bda917de1 100644 --- a/service_mesh/v2x/ossm-about.adoc +++ b/service_mesh/v2x/ossm-about.adoc @@ -1,7 +1,7 @@ :_content-type: ASSEMBLY [id="ossm-about"] = About OpenShift Service Mesh -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-about toc::[] diff --git a/service_mesh/v2x/ossm-architecture.adoc b/service_mesh/v2x/ossm-architecture.adoc index 2bde33a30ee9..19db71b7b515 100644 --- a/service_mesh/v2x/ossm-architecture.adoc +++ b/service_mesh/v2x/ossm-architecture.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="ossm-architecture"] = Understanding Service Mesh -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-architecture toc::[] -{ProductName} provides a platform for behavioral insight and operational control over your networked microservices in a service mesh. With {ProductName}, you can connect, secure, and monitor microservices in your {product-title} environment. +{SMProductName} provides a platform for behavioral insight and operational control over your networked microservices in a service mesh. With {SMProductName}, you can connect, secure, and monitor microservices in your {product-title} environment. include::modules/ossm-understanding-service-mesh.adoc[leveloffset=+1] @@ -45,4 +45,4 @@ include::modules/distr-tracing-features.adoc[leveloffset=+2] == Next steps -* xref:../../service_mesh/v2x/preparing-ossm-installation.adoc#preparing-ossm-installation[Prepare to install {ProductName}] in your {product-title} environment. +* xref:../../service_mesh/v2x/preparing-ossm-installation.adoc#preparing-ossm-installation[Prepare to install {SMProductName}] in your {product-title} environment. diff --git a/service_mesh/v2x/ossm-create-mesh.adoc b/service_mesh/v2x/ossm-create-mesh.adoc index f16cd095f2df..37ef9c88f200 100644 --- a/service_mesh/v2x/ossm-create-mesh.adoc +++ b/service_mesh/v2x/ossm-create-mesh.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="ossm-create-mesh"] = Adding services to a service mesh -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-create-mesh -After installing the Operators and `ServiceMeshControlPlane` resource, add applications, workloads, or services to your mesh by creating a `ServiceMeshMemberRoll` resource and specifying the namespaces where your content is located. If you already have an application, workload, or service to add to a `ServiceMeshMemberRoll` resource, use the following steps. Or, to install a sample application called Bookinfo and add it to a `ServiceMeshMemberRoll` resource, skip to the tutorial for installing the xref:../../service_mesh/v2x/ossm-create-mesh.adoc#ossm-tutorial-bookinfo-overview_ossm-create-mesh[Bookinfo example application] to see how an application works in {ProductName}. +After installing the Operators and `ServiceMeshControlPlane` resource, add applications, workloads, or services to your mesh by creating a `ServiceMeshMemberRoll` resource and specifying the namespaces where your content is located. If you already have an application, workload, or service to add to a `ServiceMeshMemberRoll` resource, use the following steps. Or, to install a sample application called Bookinfo and add it to a `ServiceMeshMemberRoll` resource, skip to the tutorial for installing the xref:../../service_mesh/v2x/ossm-create-mesh.adoc#ossm-tutorial-bookinfo-overview_ossm-create-mesh[Bookinfo example application] to see how an application works in {SMProductName}. -The items listed in the `ServiceMeshMemberRoll` resource are the applications and workflows that are managed by the `ServiceMeshControlPlane` resource. The control plane, which includes the {ProductShortName} Operators, Istiod, and `ServiceMeshControlPlane`, and the data plane, which includes applications and Envoy proxy, must be in separate namespaces. +The items listed in the `ServiceMeshMemberRoll` resource are the applications and workflows that are managed by the `ServiceMeshControlPlane` resource. The control plane, which includes the {SMProductShortName} Operators, Istiod, and `ServiceMeshControlPlane`, and the data plane, which includes applications and Envoy proxy, must be in separate namespaces. [NOTE] ==== diff --git a/service_mesh/v2x/ossm-create-smcp.adoc b/service_mesh/v2x/ossm-create-smcp.adoc index ab84d89c55b7..cf36bc8a3985 100644 --- a/service_mesh/v2x/ossm-create-smcp.adoc +++ b/service_mesh/v2x/ossm-create-smcp.adoc @@ -1,14 +1,14 @@ :_content-type: ASSEMBLY [id="ossm-create-smcp"] = Creating the ServiceMeshControlPlane -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-create-smcp You can deploy a basic installation of the `ServiceMeshControlPlane` by using either the {product-title} web console or from the command line using the `oc` client tool. [NOTE] ==== -The {ProductShortName} documentation uses `istio-system` as the example project, but you can deploy the service mesh to any project. +The {SMProductShortName} documentation uses `istio-system` as the example project, but you can deploy the service mesh to any project. ==== [NOTE] @@ -20,8 +20,8 @@ include::modules/ossm-control-plane-web.adoc[leveloffset=+1] include::modules/ossm-control-plane-cli.adoc[leveloffset=+1] -{ProductName} supports multiple independent control planes within the cluster. You can create reusable configurations with `ServiceMeshControlPlane` profiles. For more information, see xref:../../service_mesh/v2x/ossm-profiles-users.adoc#ossm-control-plane-profiles_ossm-profiles-users[Creating control plane profiles]. +{SMProductName} supports multiple independent control planes within the cluster. You can create reusable configurations with `ServiceMeshControlPlane` profiles. For more information, see xref:../../service_mesh/v2x/ossm-profiles-users.adoc#ossm-control-plane-profiles_ossm-profiles-users[Creating control plane profiles]. == Next steps -Create a `ServiceMeshMemberRoll` resource to specify the namespaces associated with the {ProductShortName}. For more information, see xref:../../service_mesh/v2x/ossm-create-mesh.adoc#ossm-create-mesh[Adding services to a service mesh]. +Create a `ServiceMeshMemberRoll` resource to specify the namespaces associated with the {SMProductShortName}. For more information, see xref:../../service_mesh/v2x/ossm-create-mesh.adoc#ossm-create-mesh[Adding services to a service mesh]. diff --git a/service_mesh/v2x/ossm-deploy-production.adoc b/service_mesh/v2x/ossm-deploy-production.adoc index bad3874dc9c2..c139ba5a4e31 100644 --- a/service_mesh/v2x/ossm-deploy-production.adoc +++ b/service_mesh/v2x/ossm-deploy-production.adoc @@ -1,7 +1,7 @@ :_content-type: ASSEMBLY [id="ossm-production"] = Configuring Service Mesh for production -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-architecture toc::[] @@ -9,7 +9,7 @@ When you are ready to move from a basic installation to production, you must con .Prerequisites -* Install and configure {ProductName}. +* Install and configure {SMProductName}. * Test your configuration in a staging environment. include::modules/ossm-smcp-prod.adoc[leveloffset=+1] @@ -18,4 +18,4 @@ include::modules/ossm-smcp-prod.adoc[leveloffset=+1] [role="_additional-resources"] == Additional resources -* For more information about tuning {ProductShortName} for performance, see xref:../../service_mesh/v2x/ossm-performance-scalability.adoc#ossm-performance-scalability[Performance and scalability]. +* For more information about tuning {SMProductShortName} for performance, see xref:../../service_mesh/v2x/ossm-performance-scalability.adoc#ossm-performance-scalability[Performance and scalability]. diff --git a/service_mesh/v2x/ossm-deployment-models.adoc b/service_mesh/v2x/ossm-deployment-models.adoc index 4d2de2e4cc88..dd2bf55bbba1 100644 --- a/service_mesh/v2x/ossm-deployment-models.adoc +++ b/service_mesh/v2x/ossm-deployment-models.adoc @@ -1,10 +1,10 @@ :_content-type: ASSEMBLY [id="ossm-deployment-models"] = Service mesh deployment models -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-deployment-models -{ProductName} supports several different deployment models that can be combined in different ways to best suit your business requirements. +{SMProductName} supports several different deployment models that can be combined in different ways to best suit your business requirements. include::modules/ossm-deploy-single-mesh.adoc[leveloffset=+1] diff --git a/service_mesh/v2x/ossm-distr-tracing.adoc b/service_mesh/v2x/ossm-distr-tracing.adoc index 5e651ea32e26..67c15b19fd93 100644 --- a/service_mesh/v2x/ossm-distr-tracing.adoc +++ b/service_mesh/v2x/ossm-distr-tracing.adoc @@ -1,7 +1,7 @@ :_content-type: ASSEMBLY [id="ossm-dist-trac"] = Distributed tracing -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-dist-trac toc::[] @@ -11,7 +11,7 @@ toc::[] Distributed Tracing is the process of tracking the performance of individual services in an application by tracing the path of the service calls in the application. Each time a user takes action in an application, a request is executed that might require many services to interact to produce a response. The path of this request is called a distributed transaction. -As a developer, you can use the {JaegerShortName} to visualize call flows in a microservice application with {ProductName}. +As a developer, you can use the {JaegerShortName} to visualize call flows in a microservice application with {SMProductName}. include::modules/ossm-config-sampling.adoc[leveloffset=+1] diff --git a/service_mesh/v2x/ossm-extensions.adoc b/service_mesh/v2x/ossm-extensions.adoc index 3ba0def748ce..f02c1fc655ae 100644 --- a/service_mesh/v2x/ossm-extensions.adoc +++ b/service_mesh/v2x/ossm-extensions.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="ossm-extensions"] = Extensions -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-extensions toc::[] -You can use WebAssembly extensions to add new features directly into the {ProductName} proxies, allowing you to move even more common functionality out of your applications, and implement them in a single language that compiles to WebAssembly bytecode. +You can use WebAssembly extensions to add new features directly into the {SMProductName} proxies, allowing you to move even more common functionality out of your applications, and implement them in a single language that compiles to WebAssembly bytecode. == WebAssembly extensions @@ -14,17 +14,17 @@ WebAssembly modules can be run on many platforms, including proxies, and has bro .Extension Capabilities -{ProductName} extensions are link:https://www.envoyproxy.io/docs/envoy/v1.16.0/intro/arch_overview/http/http_filters#arch-overview-http-filters[Envoy HTTP Filters], giving them a wide range of capabilities: +{SMProductName} extensions are link:https://www.envoyproxy.io/docs/envoy/v1.16.0/intro/arch_overview/http/http_filters#arch-overview-http-filters[Envoy HTTP Filters], giving them a wide range of capabilities: * Manipulating the body and headers of requests and responses * Out-of-band HTTP requests to services not in the request path, such as authentication or policy checking * Side-channel data storage and queues for filters to communicate with each other -There are two parts to writing a {ProductName} extension: you'll have to write your extension using an SDK that exposes the link:https://github.com/proxy-wasm/spec[proxy-wasm API] and compile it to a WebAssembly module, and then package it into a container. +There are two parts to writing a {SMProductName} extension: you'll have to write your extension using an SDK that exposes the link:https://github.com/proxy-wasm/spec[proxy-wasm API] and compile it to a WebAssembly module, and then package it into a container. .Supported languages -You can use any language that compiles to WebAssembly bytecode to write a {ProductName} extension, but the following languages have existing SDKs that expose the proxy-wasm API so that it can be consumed directly. +You can use any language that compiles to WebAssembly bytecode to write a {SMProductName} extension, but the following languages have existing SDKs that expose the proxy-wasm API so that it can be consumed directly. .Supported languages |=== diff --git a/service_mesh/v2x/ossm-federation.adoc b/service_mesh/v2x/ossm-federation.adoc index b7e4b1331885..d41bfc35fa6f 100644 --- a/service_mesh/v2x/ossm-federation.adoc +++ b/service_mesh/v2x/ossm-federation.adoc @@ -1,7 +1,7 @@ :_content-type: ASSEMBLY [id="ossm-federation"] = Connecting service meshes -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: federation toc::[] diff --git a/service_mesh/v2x/ossm-observability.adoc b/service_mesh/v2x/ossm-observability.adoc index b8fd509cfb35..1d01edcd15f0 100644 --- a/service_mesh/v2x/ossm-observability.adoc +++ b/service_mesh/v2x/ossm-observability.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="ossm-observability"] = Metrics, logs, and traces -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: observability toc::[] -Once you have added your application to the mesh, you can observe the data flow through your application. If you do not have your own application installed, you can see how observability works in {ProductName} by installing the xref:../../service_mesh/v2x/prepare-to-deploy-applications-ossm.adoc#ossm-tutorial-bookinfo-overview_ossm-create-mesh[Bookinfo sample application]. +Once you have added your application to the mesh, you can observe the data flow through your application. If you do not have your own application installed, you can see how observability works in {SMProductName} by installing the xref:../../service_mesh/v2x/prepare-to-deploy-applications-ossm.adoc#ossm-tutorial-bookinfo-overview_ossm-create-mesh[Bookinfo sample application]. include::modules/ossm-observability-addresses.adoc[leveloffset=+1] diff --git a/service_mesh/v2x/ossm-performance-scalability.adoc b/service_mesh/v2x/ossm-performance-scalability.adoc index 3195dbc6fa0c..7e6a9db5bcb9 100644 --- a/service_mesh/v2x/ossm-performance-scalability.adoc +++ b/service_mesh/v2x/ossm-performance-scalability.adoc @@ -1,7 +1,7 @@ :_content-type: ASSEMBLY [id="ossm-performance-scalability"] = Performance and scalability -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: performance-scalability toc::[] diff --git a/service_mesh/v2x/ossm-profiles-users.adoc b/service_mesh/v2x/ossm-profiles-users.adoc index 5ad2a1a93b5c..b8d03a22d69b 100644 --- a/service_mesh/v2x/ossm-profiles-users.adoc +++ b/service_mesh/v2x/ossm-profiles-users.adoc @@ -1,7 +1,7 @@ :_content-type: ASSEMBLY [id="ossm-profiles-users"] = Managing users and profiles -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-profiles-users toc::[] diff --git a/service_mesh/v2x/ossm-reference-jaeger.adoc b/service_mesh/v2x/ossm-reference-jaeger.adoc index b807825c2621..6921b3057667 100644 --- a/service_mesh/v2x/ossm-reference-jaeger.adoc +++ b/service_mesh/v2x/ossm-reference-jaeger.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="jaeger-config-ref"] = Jaeger configuration reference -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: jaeger-config-reference toc::[] -When the {ProductShortName} Operator deploys the `ServiceMeshControlPlane` resource, it can also create the resources for distributed tracing. {ProductShortName} uses Jaeger for distributed tracing. +When the {SMProductShortName} Operator deploys the `ServiceMeshControlPlane` resource, it can also create the resources for distributed tracing. {SMProductShortName} uses Jaeger for distributed tracing. include::modules/ossm-enabling-jaeger.adoc[leveloffset=+1] diff --git a/service_mesh/v2x/ossm-reference-smcp.adoc b/service_mesh/v2x/ossm-reference-smcp.adoc index 54023e3e1211..c299bdc0ee85 100644 --- a/service_mesh/v2x/ossm-reference-smcp.adoc +++ b/service_mesh/v2x/ossm-reference-smcp.adoc @@ -1,10 +1,10 @@ :_content-type: ASSEMBLY [id="ossm-reference"] = Service Mesh control plane configuration reference -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-reference -You can customize your {ProductName} by modifying the default `ServiceMeshControlPlane` (SMCP) resource or by creating a completely custom SMCP resource. This reference section documents the configuration options available for the SMCP resource. +You can customize your {SMProductName} by modifying the default `ServiceMeshControlPlane` (SMCP) resource or by creating a completely custom SMCP resource. This reference section documents the configuration options available for the SMCP resource. include::modules/ossm-cr-example.adoc[leveloffset=+1] diff --git a/service_mesh/v2x/ossm-security.adoc b/service_mesh/v2x/ossm-security.adoc index b6c16e237da8..3662f5ad3582 100644 --- a/service_mesh/v2x/ossm-security.adoc +++ b/service_mesh/v2x/ossm-security.adoc @@ -1,13 +1,13 @@ :_content-type: ASSEMBLY [id="ossm-security"] = Security -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-security toc::[] -If your service mesh application is constructed with a complex array of microservices, you can use {ProductName} to customize the security of the communication between those services. The infrastructure of {product-title} along with the traffic management features of {ProductShortName} help you manage the complexity of your applications and secure microservices. +If your service mesh application is constructed with a complex array of microservices, you can use {SMProductName} to customize the security of the communication between those services. The infrastructure of {product-title} along with the traffic management features of {SMProductShortName} help you manage the complexity of your applications and secure microservices. .Before you begin diff --git a/service_mesh/v2x/ossm-support.adoc b/service_mesh/v2x/ossm-support.adoc index d16ebe9e7af3..608e6982cec2 100644 --- a/service_mesh/v2x/ossm-support.adoc +++ b/service_mesh/v2x/ossm-support.adoc @@ -1,7 +1,7 @@ :_content-type: ASSEMBLY [id="ossm-support"] = Getting support -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-support toc::[] @@ -10,7 +10,7 @@ include::modules/support.adoc[leveloffset=+1] The `must-gather` tool enables you to collect diagnostic information about your {product-title} cluster, including virtual machines and other data related to -{ProductName}. You can send that diagnostic information to support for both {product-title} and {ProductName}. +{SMProductName}. You can send that diagnostic information to support for both {product-title} and {SMProductName}. include::modules/about-must-gather.adoc[leveloffset=+1] diff --git a/service_mesh/v2x/ossm-threescale-webassembly-module.adoc b/service_mesh/v2x/ossm-threescale-webassembly-module.adoc index 5dedd0a5c7da..26291d08238f 100644 --- a/service_mesh/v2x/ossm-threescale-webassembly-module.adoc +++ b/service_mesh/v2x/ossm-threescale-webassembly-module.adoc @@ -1,14 +1,14 @@ :_content-type: ASSEMBLY [id="ossm-threescale-webassembly-module"] = Using the 3scale WebAssembly module -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-threescale-webassembly-module toc::[] [NOTE] ==== -The `threescale-wasm-auth` module runs on integrations of 3scale API Management 2.11 or later with {ProductName} 2.1.0 or later. +The `threescale-wasm-auth` module runs on integrations of 3scale API Management 2.11 or later with {SMProductName} 2.1.0 or later. ==== The `threescale-wasm-auth` module is a link:https://webassembly.org[WebAssembly] module that uses a set of interfaces, known as an application binary interfaces (_ABI_). This is defined by the link:https://github.com/proxy-wasm/spec[_Proxy-WASM_] specification to drive any piece of software that implements the ABI so it can authorize HTTP requests against 3scale. @@ -27,7 +27,7 @@ The `threescale-wasm-auth` module is designed to be fully compatible with all im [id="usage-as-a-stand-alone-module_ossm-threescale-webassembly-module"] == Usage as a stand-alone module -Because of its self-contained design, it is possible to configure this module to work with Proxy-WASM proxies independently of {ProductShortName}, as well as 3scale Istio adapter deployments. +Because of its self-contained design, it is possible to configure this module to work with Proxy-WASM proxies independently of {SMProductShortName}, as well as 3scale Istio adapter deployments. [id="prerequisites_ossm-threescale-webassembly-module"] == Prerequisites diff --git a/service_mesh/v2x/ossm-traffic-manage.adoc b/service_mesh/v2x/ossm-traffic-manage.adoc index ce37e40e595e..ba6058c7186a 100644 --- a/service_mesh/v2x/ossm-traffic-manage.adoc +++ b/service_mesh/v2x/ossm-traffic-manage.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="ossm-routing-traffic"] = Configuring traffic management -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: routing-traffic toc::[] -{ProductName} allows you to control the flow of traffic and API calls between services. Some services in your service mesh may need to communicate within the mesh and others may need to be hidden. Manage the traffic to hide specific backend services, expose services, create testing or versioning deployments, or add a security layer on a set of services. +{SMProductName} allows you to control the flow of traffic and API calls between services. Some services in your service mesh may need to communicate within the mesh and others may need to be hidden. Manage the traffic to hide specific backend services, expose services, create testing or versioning deployments, or add a security layer on a set of services. This guide references the Bookinfo sample application to provide examples of routing in an example application. Install the xref:../../service_mesh/v2x/prepare-to-deploy-applications-ossm.adoc#ossm-tutorial-bookinfo-overview_ossm-create-mesh[Bookinfo application] to learn how these routing examples work. @@ -27,12 +27,12 @@ include::modules/ossm-routing-gateways.adoc[leveloffset=+1] [id="ossm-auto-route_{context}"] == Automatic routes -OpenShift routes for Istio Gateways are automatically managed in {ProductShortName}. 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 {SMProductShortName}. 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-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 xref:../../networking/ingress-operator.adoc#using-wildcard-routes_configuring-ingress[Using wildcard routes]. +{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 xref:../../networking/ingress-operator.adoc#using-wildcard-routes_configuring-ingress[Using wildcard routes]. include::modules/ossm-auto-route.adoc[leveloffset=+2] diff --git a/service_mesh/v2x/ossm-troubleshooting-istio.adoc b/service_mesh/v2x/ossm-troubleshooting-istio.adoc index 993ba2746ae9..a69fa4a58593 100644 --- a/service_mesh/v2x/ossm-troubleshooting-istio.adoc +++ b/service_mesh/v2x/ossm-troubleshooting-istio.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="ossm-troubleshooting"] = Troubleshooting your service mesh -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: troubleshooting-ossm toc::[] -This section describes how to identify and resolve common problems in {ProductName}. Use the following sections to help troubleshoot and debug problems when deploying {ProductName} on {product-title}. +This section describes how to identify and resolve common problems in {SMProductName}. Use the following sections to help troubleshoot and debug problems when deploying {SMProductName} on {product-title}. // The following include statements pull in the module files that comprise the assembly. @@ -30,7 +30,7 @@ include::modules/ossm-troubleshooting-operators.adoc[leveloffset=+2] == Troubleshooting the control plane -The Service Mesh _control plane_ is composed of Istiod, which consolidates several previous control plane components (Citadel, Galley, Pilot) into a single binary. Deploying the `ServiceMeshControlPlane` also creates the other components that make up {ProductName} as described in the xref:../../service_mesh/v2x/ossm-architecture.adoc#ossm-architecture_ossm-architecture[architecture] topic. +The Service Mesh _control plane_ is composed of Istiod, which consolidates several previous control plane components (Citadel, Galley, Pilot) into a single binary. Deploying the `ServiceMeshControlPlane` also creates the other components that make up {SMProductName} as described in the xref:../../service_mesh/v2x/ossm-architecture.adoc#ossm-architecture_ossm-architecture[architecture] topic. include::modules/ossm-validating-smcp.adoc[leveloffset=+2] @@ -44,7 +44,7 @@ include::modules/ossm-troubleshooting-smcp.adoc[leveloffset=+2] The _data plane_ is a set of intelligent proxies that intercept and control all inbound and outbound network communications between services in the service mesh. -{ProductName} relies on a proxy sidecar within the application’s pod to provide service mesh capabilities to the application. +{SMProductName} relies on a proxy sidecar within the application’s pod to provide service mesh capabilities to the application. include::modules/ossm-troubleshooting-injection.adoc[leveloffset=+2] @@ -64,6 +64,6 @@ include::modules/about-must-gather.adoc[leveloffset=+2] include::modules/ossm-about-collecting-ossm-data.adoc[leveloffset=+2] -For prompt support, supply diagnostic information for both {product-title} and {ProductName}. +For prompt support, supply diagnostic information for both {product-title} and {SMProductName}. include::modules/support-submitting-a-case.adoc[leveloffset=+2] diff --git a/service_mesh/v2x/ossm-vs-community.adoc b/service_mesh/v2x/ossm-vs-community.adoc index 5303cb4994ca..5189d6c89fe0 100644 --- a/service_mesh/v2x/ossm-vs-community.adoc +++ b/service_mesh/v2x/ossm-vs-community.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="ossm-vs-community"] = Service Mesh and Istio differences -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-vs-istio toc::[] -{ProductName} differs from an installation of Istio to provide additional features or to handle differences when deploying on {product-title}. +{SMProductName} differs from an installation of Istio to provide additional features or to handle differences when deploying on {product-title}. // The following include statements pull in the module files that comprise the assembly. diff --git a/service_mesh/v2x/prepare-to-deploy-applications-ossm.adoc b/service_mesh/v2x/prepare-to-deploy-applications-ossm.adoc index a8af872fc0c7..230e76d6d7b6 100644 --- a/service_mesh/v2x/prepare-to-deploy-applications-ossm.adoc +++ b/service_mesh/v2x/prepare-to-deploy-applications-ossm.adoc @@ -1,7 +1,7 @@ :_content-type: ASSEMBLY [id="deploying-applications-ossm"] = Enabling sidecar injection -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: deploying-applications-ossm toc::[] @@ -23,7 +23,7 @@ include::modules/ossm-sidecar-injection-env-var.adoc[leveloffset=+1] == Next steps -Configure {ProductName} features for your environment. +Configure {SMProductName} features for your environment. * xref:../../service_mesh/v2x/ossm-security.adoc#ossm-security[Security] * xref:../../service_mesh/v2x/ossm-traffic-manage.adoc#ossm-routing-traffic[Traffic management] diff --git a/service_mesh/v2x/preparing-ossm-installation.adoc b/service_mesh/v2x/preparing-ossm-installation.adoc index 686c19c60a3a..c1715da07f41 100644 --- a/service_mesh/v2x/preparing-ossm-installation.adoc +++ b/service_mesh/v2x/preparing-ossm-installation.adoc @@ -1,18 +1,18 @@ :_content-type: ASSEMBLY [id="preparing-ossm-installation"] = Preparing to install Service Mesh -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: preparing-ossm-installation toc::[] -Before you can install {ProductName}, you must subscribe to {product-title} and install {product-title} in a supported configuration. +Before you can install {SMProductName}, you must subscribe to {product-title} and install {product-title} in a supported configuration. == Prerequisites * Maintain an active {product-title} subscription on your Red Hat account. If you do not have a subscription, contact your sales representative for more information. * Review the xref:../../architecture/architecture-installation.adoc#installation-overview_architecture-installation[{product-title} {product-version} overview]. -* Install {product-title} {product-version}. If you are installing {ProductName} on a xref:../../installing/installing-preparing.adoc#supported-installation-methods-for-different-platforms[restricted network], follow the instructions for your chosen {product-title} infrastructure. +* Install {product-title} {product-version}. If you are installing {SMProductName} on a xref:../../installing/installing-preparing.adoc#supported-installation-methods-for-different-platforms[restricted network], follow the instructions for your chosen {product-title} infrastructure. ** xref:../../installing/installing_aws/installing-aws-account.adoc#installing-aws-account[Install {product-title} {product-version} on AWS] ** xref:../../installing/installing_aws/installing-aws-user-infra.adoc#installing-aws-user-infra[Install {product-title} {product-version} on user-provisioned AWS] ** xref:../../installing/installing_bare_metal/installing-bare-metal.adoc#installing-bare-metal[Install {product-title} {product-version} on bare metal] @@ -27,4 +27,4 @@ include::modules/ossm-supported-configurations.adoc[leveloffset=+1] == Next steps -* xref:../../service_mesh/v2x/installing-ossm.adoc#installing-ossm[Install {ProductName}] in your {product-title} environment. +* xref:../../service_mesh/v2x/installing-ossm.adoc#installing-ossm[Install {SMProductName}] in your {product-title} environment. diff --git a/service_mesh/v2x/removing-ossm.adoc b/service_mesh/v2x/removing-ossm.adoc index 2c6b690bb128..d2046ba0d01c 100644 --- a/service_mesh/v2x/removing-ossm.adoc +++ b/service_mesh/v2x/removing-ossm.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="removing-ossm"] = Uninstalling Service Mesh -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: removing-ossm toc::[] -To uninstall {ProductName} from an existing {product-title} instance and remove its resources, you must delete the control plane, delete the Operators, and run commands to manually remove some resources. +To uninstall {SMProductName} from an existing {product-title} instance and remove its resources, you must delete the control plane, delete the Operators, and run commands to manually remove some resources. include::modules/ossm-control-plane-remove.adoc[leveloffset=+1] diff --git a/service_mesh/v2x/servicemesh-release-notes.adoc b/service_mesh/v2x/servicemesh-release-notes.adoc index 324d64d3b030..f431d85b5b81 100644 --- a/service_mesh/v2x/servicemesh-release-notes.adoc +++ b/service_mesh/v2x/servicemesh-release-notes.adoc @@ -1,7 +1,7 @@ :_content-type: ASSEMBLY [id="service-mesh-release-notes"] = Service Mesh Release Notes -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-release-notes toc::[] diff --git a/service_mesh/v2x/threescale-adapter.adoc b/service_mesh/v2x/threescale-adapter.adoc index fea99d5efe81..fb80d0958621 100644 --- a/service_mesh/v2x/threescale-adapter.adoc +++ b/service_mesh/v2x/threescale-adapter.adoc @@ -1,17 +1,17 @@ :_content-type: ASSEMBLY [id="threescale-adapter"] = Using the 3scale Istio adapter -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: threescale-adapter toc::[] -The 3scale Istio Adapter is an optional adapter that allows you to label a service running within the {ProductName} and integrate that service with the 3scale API Management solution. -It is not required for {ProductName}. +The 3scale Istio Adapter is an optional adapter that allows you to label a service running within the {SMProductName} and integrate that service with the 3scale API Management solution. +It is not required for {SMProductName}. [IMPORTANT] ==== -You can only use the 3scale Istio adapter with {ProductName} versions 2.0 and below. The Mixer component was deprecated in release 2.0 and removed in release 2.1. For {ProductName} versions 2.1.0 and later you should use the xref:../../service_mesh/v2x/ossm-threescale-webassembly-module.adoc[3scale WebAssembly module]. +You can only use the 3scale Istio adapter with {SMProductName} versions 2.0 and below. The Mixer component was deprecated in release 2.0 and removed in release 2.1. For {SMProductName} versions 2.1.0 and later you should use the xref:../../service_mesh/v2x/ossm-threescale-webassembly-module.adoc[3scale WebAssembly module]. If you want to enable 3scale backend cache with the 3scale Istio adapter, you must also enable Mixer policy and Mixer telemetry. See xref:../../service_mesh/v2x/ossm-create-smcp.adoc#ossm-create-smcp[Deploying the Red Hat OpenShift Service Mesh control plane]. ==== diff --git a/service_mesh/v2x/upgrading-ossm.adoc b/service_mesh/v2x/upgrading-ossm.adoc index 62b28dcf0e73..276ccc804043 100644 --- a/service_mesh/v2x/upgrading-ossm.adoc +++ b/service_mesh/v2x/upgrading-ossm.adoc @@ -1,12 +1,12 @@ :_content-type: ASSEMBLY [id="upgrading-ossm"] = Upgrading Service Mesh -include::_attributes/ossm-document-attributes.adoc[] +include::_attributes/common-attributes.adoc[] :context: ossm-upgrade toc::[] -To access the most current features of {ProductName}, upgrade to the current version, {ProductVersion}. +To access the most current features of {SMProductName}, upgrade to the current version, {SMProductVersion}. //// The following include statements pull in the module files that comprise the assembly.