Repository: openshift/openshift-docs
Pull request #89396: OSSM-8509: Cluster-wide migration using the Istio revision label  with cert manager
Author: login: rh-tokeefe
Labels: name: peer-review-done
description: Signifies that the peer review team has reviewed this PR
name: size/L
description: Denotes a PR that changes 100-499 lines, ignoring generated files.
name: jira/valid-reference
description: Indicates that this PR references a valid Jira ticket of any type.
Created: 2025-02-28T16:19:33Z | Merged: 2025-03-11T08:08:23Z

Merge to: https://github.com/openshift/openshift-docs/tree/service-mesh-docs-main
Cherry pick to: https://github.com/openshift/openshift-docs/tree/service-mesh-docs-3.0

Version(s): Technology Preview

Issue: https://issues.redhat.com/browse/OSSM-8509
<!--- Add a link to the Bugzilla, Jira, or GitHub issue, if applicable. --->

Link to docs preview: https://89396--ocpdocs-pr.netlify.app/openshift-service-mesh/latest/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.html#ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_ossm-migrating-cluster-wide-assembly
<!--- Add direct link(s) to the exact page(s) with updated content from the preview build. --->

QE review:
- [x] QE has approved this change.
<!--- QE approval is required to merge a PR except for changes that do not impact the meaning of the docs. --->

Additional information:
<!--- Optional: Include additional context or expand the description here.--->

<!--- After you open your PR, ask for review from the OpenShift docs team:
  For community authors: Tag @openshift/team-documentation in a GitHub comment.--->



Diff:
diff --git a/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc b/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
index 1094e74e409c..a957603788c8 100644
--- a/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+++ b/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
@@ -1,3 +1,7 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
 :_mod-docs-content-type: ASSEMBLY
 [id=ossm-migrating-cluster-wide-assembly]
 = Cluster-wide migration guide
@@ -17,31 +21,41 @@ include::modules/ossm-control-plane-configuration-migration-requirements.adoc[le
 
 include::modules/ossm-cluster-wide-migration-methods.adoc[leveloffset=+1]
 
+
 // The following tasks are for migration using the Istio revision label
+
 include::modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label.adoc[leveloffset=+1]
 
-[role="_additional-resources"]
-.Additional resources
+include::modules/ossm-migrating-workloads-using-the-istio-revision-label.adoc[leveloffset=+2]
 
-* xref:../../install/ossm-sidecar-injection-assembly.adoc#ossm-identifying-revision-name_ossm-sidecar-injection-assembly[Identifying the revision name]
+.Next steps
 
-include::modules/ossm-migrating-workloads-using-the-istio-revision-label.adoc[leveloffset=+2]
+If you are using gateways, you must migrate them before you complete the migration process.
 
-include::modules/ossm-creating-a-default-revision-tag-and-relabeling-the-namespaces.adoc[leveloffset=+1]
+* xref:../../migrating/migrating-gateways/ossm-migrating-gateways-assembly.adoc[Migrating gateways from Service Mesh 2 to Service Mesh 3]
+
+If you are not using gateways, and have verified your cluster-wide migration, you can proceed to complete the migration and remove {SMProduct} 2 resources.
+
+* xref:../../migrating/done/ossm-migrating-complete-assembly.adoc[Completing the Migration]
+
+//The following tasks are for the Istio revision label with cert-manager
+include::modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc[leveloffset=+1]
+
+include::modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc[leveloffset=+2]
 
 .Next steps
 
-You can proceed to complete the migration and remove {SMProduct} 2 resources.
+If you are using gateways, you must migrate them before you complete the migration process.
 
-* xref:../../migrating/done/ossm-migrating-complete-assembly.adoc[Completing the Migration]
+* xref:../../migrating/migrating-gateways/ossm-migrating-gateways-assembly.adoc[Migrating gateways from Service Mesh 2 to Service Mesh 3]
 
-// The following tasks are for migration using the Istio injection label
-include::modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-injection-label.adoc[leveloffset=+1]
+If you are not using gateways, and have verified your cluster-wide migration, you can proceed to complete the migration and remove {SMProduct} 2 resources.
 
-[role="_additional-resources"]
-.Additional resources
+* xref:../../migrating/done/ossm-migrating-complete-assembly.adoc[Completing the Migration]
 
-* xref:../../install/ossm-sidecar-injection-assembly.adoc#ossm-identifying-revision-name_ossm-sidecar-injection-assembly[Identifying the revision name]
+// The following tasks are for the Istio injection label
+
+include::modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-injection-label.adoc[leveloffset=+1]
 
 include::modules/ossm-migrating-workloads-using-the-istio-injection-label.adoc[leveloffset=+2]
 
@@ -53,6 +67,14 @@ If you are using gateways, you must migrate them before you complete the migrati
 
 If you are not using gateways, and have verified your cluster-wide migration, create a default revision tag and re-label namespaces.
 
+include::modules/ossm-creating-a-default-revision-tag-and-relabeling-the-namespaces.adoc[leveloffset=+2]
+
+.Next steps
+
+You can proceed to complete the migration and remove {SMProduct} 2 resources.
+
+* xref:../../migrating/done/ossm-migrating-complete-assembly.adoc[Completing the Migration]
+
 [IMPORTANT]
 ====
 Before creating a default revision tag and relabelling the namespaces, you must migrate all remaining workload namespaces, including gateways.
@@ -61,3 +83,7 @@ Before creating a default revision tag and relabelling the namespaces, you must
 // insert xref to "Creating the default revision tag and relabeling the namespaces" after PR OSSM-9000 is merged
 
 * Creating the default revision tag and relabeling the namespaces
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../install/ossm-sidecar-injection-assembly.adoc#ossm-identifying-revision-name_ossm-sidecar-injection-assembly[Identifying the revision name]
diff --git a/modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc b/modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
new file mode 100644
index 000000000000..33d1a9219e92
--- /dev/null
+++ b/modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
@@ -0,0 +1,132 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` application is used as an example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3."
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have installed the {SMProduct} {SMv2Version} Operator.
+* You have installed the {SMProduct} 3 Operator.
+* You have created an `IstioCNI` resource.
+* You have installed the `istioctl` tool.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager tool.
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,ossm-3-v1-24-3}" <1>
+----
++
+<1> The `app.istio.revisions` field must include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Identify the namespaces that contain a 2.6 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get smcp -A
+----
++
+.Example output:
+[source,terminal]
+----
+NAMESPACE      NAME                   READY   STATUS            PROFILES      VERSION       AGE
+istio-system   install-istio-system   6/6     ComponentsReady   ["default"]   2.6.6         115m
+----
+
+. Create a YAML file named `ossm-3.yaml`. This procedure creates the {istio} resource for the 3.0 installation in the same namespace as the `ServiceMeshControlPlane` resource for the 2.6 installation:
++
+.Example `Istio` resource
+[source,yaml,subs="attributes,verbatim"]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: ossm-3 # <1>
+spec:
+  updateStrategy:
+    type: RevisionBased
+  namespace: istio-system # <2>
+  version: v1.24.3
+  values:  
+    meshConfig:
+      extensionProviders: # <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+            port: 4317
+            service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+    global:
+      caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
+----
+<1> The `name`, `updateStrategy`, and `version` fields specify how the `IstioRevision` resource name is created. For more information, see "Identifying the revision name."
+<2> The 3.0 and 2.6 control planes must run in the same namespace.
+<3> If you are migrating metrics and tracing, update the `extensionProviders` fields according to your tracing and metrics configurations.
+
+. Apply the YAML file by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f ossm-3.yaml
+----
+
+. Verify that the new `istiod` resource uses the existing root certificate by running the following command:
++
+[source,terminal]
+----
+$ oc logs deployments/istiod-ossm-3-v1-24-3 -n istio-system | grep 'Load signing key and cert from existing secret'
+----
++
+.Example output:
+[source,terminal]
+----
+2024-12-18T08:13:53.788959Z	info	pkica	Load signing key and cert from existing secret istio-system/istio-ca-secret
+----
\ No newline at end of file
diff --git a/modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc b/modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
new file mode 100644
index 000000000000..8578aa67d470
--- /dev/null
+++ b/modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
@@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads by using the Istio revision label with cert-manager
+
+After migrating a cluster-wide deployment, you can migrate your workloads workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+To maintain simplicity, revision tags are not used in this example. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways."
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
+
+. Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the `oc label` command performs the following actions:
+
+.. Removes the `istio-injection` label: This label prevents the 3.0 control plane from injecting the proxy. The `istio-injection` label takes precedence over `istio.io/rev` label.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace. With the label applied, {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy refuses to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface(CNI) annotations.
+
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which control plane they are connected to.
+====
+
+. Restart the workloads by using one of the following options:
++
+.. To restart all the workloads at once so that the new pods are injected with the {SMProduct} 3.0 proxy, run the following command:
++
+.Example command for `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments -n bookinfo
+----
+
+.. To restart each workload individually, run the following command for each workload:
++
+.Example command for `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments productpage-v1 -n bookinfo
+----
+
+. Wait for the `productpage` application to restart by running the following command:
++
+[source,terminal]
+----
+$ oc rollout status deployment productpage-v1 -n bookinfo
+----
+
+.Verification
+
+. Verify that the expected workloads are managed by the new control plane by running the following command:
++
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+----
++
+.Example output:
+[source,terminal]
+----
+NAME                                          CLUSTER        CDS             LDS             EDS             RDS             ECDS         ISTIOD                                           VERSION
+details-v1-7f46897b-d497c.bookinfo            Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+productpage-v1-74bfbd4d65-vsxqm.bookinfo      Kubernetes     SYNCED (4s)     SYNCED (4s)     SYNCED (3s)     SYNCED (4s)     IGNORED      istiod-ossm-3-v1-24-1-797bb4d78f-xpchx           1.24.3
+ratings-v1-559b64556-c5ppg.bookinfo           Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v1-847fb7c54d-qxt5d.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v2-5c7ff5b77b-8jbhd.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v3-5c5d764c9b-rrx8w.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+----
++
+The output shows that the `productpage-v1` deployment is the only deployment that restarted and was injected with the 3.0 proxy. Even if there are different versions of the proxies, communication between services still works.
+
+. If the 2.6 installation contains additional data plane namespaces, migrate the next namespace now.
++
+[NOTE]
+====
+Remove the `maistra.io/ignore-namespace="true"` label only after the 2.6 control plane has been uninstalled.
+====


Reviews:
user: login: nrfox
state: COMMENTED
author_association: NONE
submitted_at: 2025-03-05T14:24:32Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-06T18:16:47Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-06T18:19:43Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-06T23:41:21Z
user: login: FilipB
state: CHANGES_REQUESTED
author_association: NONE
submitted_at: 2025-03-07T14:43:19Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T14:50:32Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T14:56:37Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T14:58:25Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T14:58:56Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T15:00:27Z
user: login: FilipB
state: CHANGES_REQUESTED
author_association: NONE
submitted_at: 2025-03-07T16:36:49Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T16:59:52Z
user: login: FilipB
state: APPROVED
author_association: NONE
submitted_at: 2025-03-07T17:14:06Z
user: login: aspauldi
body: Hi, Just a few comments here and there. Looks good! 
state: COMMENTED
author_association: NONE
submitted_at: 2025-03-07T19:22:21Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T20:29:10Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T20:32:40Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T20:37:18Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T20:38:02Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T20:39:15Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T20:41:27Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T20:42:18Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T20:43:36Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T20:44:55Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T20:47:23Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T20:51:40Z
user: login: aspauldi
state: COMMENTED
author_association: NONE
submitted_at: 2025-03-07T20:52:05Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T20:52:45Z
user: login: aspauldi
state: COMMENTED
author_association: NONE
submitted_at: 2025-03-07T20:53:55Z
user: login: aspauldi
state: COMMENTED
author_association: NONE
submitted_at: 2025-03-07T20:54:28Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T22:39:00Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T22:55:58Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T22:58:02Z
user: login: xenolinux
body: I suggest to apply the same peer and merge review feedback that was provided in https://github.com/openshift/openshift-docs/pull/89324/ to be consistent since the content is nearly similar. 

I added two comments as an example. 

Gentle reminder: to squash
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-10T14:32:02Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-10T17:21:51Z
user: login: rh-tokeefe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-10T17:23:08Z

Review comments:
diff_hunk: @@ -0,0 +1,174 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment using the Istio revision label with cert-manager
+
+This procedure performs a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager-tool:
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field needs to include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Create your `Istio` resource.
++
+.Example `Istio` resource with cert-manager
++
+[source,yaml]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: istio-tenant-a
+spec:
+  namespace: istio-system-tenant-a <1>
+  version: v1.24.3
+  values:
+    meshConfig:
+      discoverySelectors:
+        - matchLabels:
+            tenant: tenant-a <2>
+      extensionProviders:  <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+           port: 4317
+          service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+  global:
+    caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: nrfox
body: indent is off. `global` should be nested under `values`
```suggestion
    global:
      caAddress: cert-manager-istio-csr.istio-system.svc:443
      pilot:
        env:
          ENABLE_CA_SERVER: "false"
```
created_at: 2025-03-05T11:57:47Z
author_association: NONE
diff_hunk: @@ -0,0 +1,174 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment using the Istio revision label with cert-manager
+
+This procedure performs a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager-tool:
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field needs to include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Create your `Istio` resource.
++
+.Example `Istio` resource with cert-manager
++
+[source,yaml]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: istio-tenant-a
+spec:
+  namespace: istio-system-tenant-a <1>
+  version: v1.24.3
+  values:
+    meshConfig:
+      discoverySelectors:
+        - matchLabels:
+            tenant: tenant-a <2>
+      extensionProviders:  <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+           port: 4317
+          service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+  global:
+    caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: nrfox
body: There are two create `Istio` steps. There should just be one. You should create your `Istio` resource after updating istio-csr and after "Identify the namespaces that contain a 2.6 ..."
created_at: 2025-03-05T14:21:00Z
author_association: NONE
diff_hunk: @@ -0,0 +1,174 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment using the Istio revision label with cert-manager
+
+This procedure performs a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager-tool:
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field needs to include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Create your `Istio` resource.
++
+.Example `Istio` resource with cert-manager
++
+[source,yaml]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: istio-tenant-a
+spec:
+  namespace: istio-system-tenant-a <1>
+  version: v1.24.3
+  values:
+    meshConfig:
+      discoverySelectors:
+        - matchLabels:
+            tenant: tenant-a <2>
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: nrfox
body: You don't need discovery selectors for the clusterwide example.
created_at: 2025-03-05T14:21:31Z
author_association: NONE
diff_hunk: @@ -0,0 +1,174 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment using the Istio revision label with cert-manager
+
+This procedure performs a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager-tool:
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field needs to include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Create your `Istio` resource.
++
+.Example `Istio` resource with cert-manager
++
+[source,yaml]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: istio-tenant-a
+spec:
+  namespace: istio-system-tenant-a <1>
+  version: v1.24.3
+  values:
+    meshConfig:
+      discoverySelectors:
+        - matchLabels:
+            tenant: tenant-a <2>
+      extensionProviders:  <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+           port: 4317
+          service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+  global:
+    caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: nrfox
body: I would just use the same yaml from the clusterwide example: https://89324--ocpdocs-pr.netlify.app/openshift-service-mesh/latest/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.html#ossm-migrating-a-cluster-wide-deployment-using-the-istio-injection-label_ossm-migrating-cluster-wide-assembly

Only add these lines nested under `values`:
```
    global:
      caAddress: cert-manager-istio-csr.istio-system.svc:443
      pilot:
        env:
          ENABLE_CA_SERVER: "false"
```
created_at: 2025-03-05T14:23:41Z
author_association: NONE
diff_hunk: @@ -0,0 +1,174 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment using the Istio revision label with cert-manager
+
+This procedure performs a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager-tool:
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field needs to include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Create your `Istio` resource.
++
+.Example `Istio` resource with cert-manager
++
+[source,yaml]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: istio-tenant-a
+spec:
+  namespace: istio-system-tenant-a <1>
+  version: v1.24.3
+  values:
+    meshConfig:
+      discoverySelectors:
+        - matchLabels:
+            tenant: tenant-a <2>
+      extensionProviders:  <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+           port: 4317
+          service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+  global:
+    caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: nrfox
body: Otherwise the output names/versions will be different in the workload snippets
created_at: 2025-03-05T14:24:29Z
author_association: NONE
diff_hunk: @@ -0,0 +1,174 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment using the Istio revision label with cert-manager
+
+This procedure performs a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager-tool:
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field needs to include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Create your `Istio` resource.
++
+.Example `Istio` resource with cert-manager
++
+[source,yaml]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: istio-tenant-a
+spec:
+  namespace: istio-system-tenant-a <1>
+  version: v1.24.3
+  values:
+    meshConfig:
+      discoverySelectors:
+        - matchLabels:
+            tenant: tenant-a <2>
+      extensionProviders:  <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+           port: 4317
+          service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+  global:
+    caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: Done
created_at: 2025-03-06T18:16:47Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,174 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment using the Istio revision label with cert-manager
+
+This procedure performs a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager-tool:
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field needs to include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Create your `Istio` resource.
++
+.Example `Istio` resource with cert-manager
++
+[source,yaml]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: istio-tenant-a
+spec:
+  namespace: istio-system-tenant-a <1>
+  version: v1.24.3
+  values:
+    meshConfig:
+      discoverySelectors:
+        - matchLabels:
+            tenant: tenant-a <2>
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: Done
created_at: 2025-03-06T18:19:43Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,174 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment using the Istio revision label with cert-manager
+
+This procedure performs a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager-tool:
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field needs to include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Create your `Istio` resource.
++
+.Example `Istio` resource with cert-manager
++
+[source,yaml]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: istio-tenant-a
+spec:
+  namespace: istio-system-tenant-a <1>
+  version: v1.24.3
+  values:
+    meshConfig:
+      discoverySelectors:
+        - matchLabels:
+            tenant: tenant-a <2>
+      extensionProviders:  <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+           port: 4317
+          service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+  global:
+    caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: deleted the first instance
created_at: 2025-03-06T23:41:21Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,137 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: FilipB
body: ```suggestion
      --set "app.istio.revisions={basic,ossm-3-v1-24-3}" <1>
```
created_at: 2025-03-07T14:32:52Z
author_association: NONE
diff_hunk: @@ -0,0 +1,137 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field must include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Identify the namespaces that contain a 2.6 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get smcp -A
+----
++
+.Sample output:
+[source,terminal]
+----
+NAMESPACE      NAME                   READY   STATUS            PROFILES      VERSION       AGE
+istio-system   install-istio-system   6/6     ComponentsReady   ["default"]   2.6.6         115m
+----
+
+. Create a YAML file named `ossm-3.yaml`. This procedure creates the {istio} resource for the 3.0 installation in the same namespace as the `ServiceMeshControlPlane` resource for the 2.6 installation.
++
+.Example `Istio` resource
+[source,yaml,subs="attributes,verbatim"]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: ossm-3 # <1>
+spec:
+  updateStrategy:
+    type: RevisionBased
+  namespace: istio-system # <2>
+  version: v1.24.3
+  values:  
+    meshConfig:
+      extensionProviders: # <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+            port: 4317
+            service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+  global:
+    caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: FilipB
body: ```suggestion
    global:
      caAddress: cert-manager-istio-csr.istio-system.svc:443
      pilot:
        env:
          ENABLE_CA_SERVER: "false"
```
created_at: 2025-03-07T14:33:44Z
author_association: NONE
diff_hunk: @@ -0,0 +1,137 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field must include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Identify the namespaces that contain a 2.6 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get smcp -A
+----
++
+.Sample output:
+[source,terminal]
+----
+NAMESPACE      NAME                   READY   STATUS            PROFILES      VERSION       AGE
+istio-system   install-istio-system   6/6     ComponentsReady   ["default"]   2.6.6         115m
+----
+
+. Create a YAML file named `ossm-3.yaml`. This procedure creates the {istio} resource for the 3.0 installation in the same namespace as the `ServiceMeshControlPlane` resource for the 2.6 installation.
++
+.Example `Istio` resource
+[source,yaml,subs="attributes,verbatim"]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: ossm-3 # <1>
+spec:
+  updateStrategy:
+    type: RevisionBased
+  namespace: istio-system # <2>
+  version: v1.24.3
+  values:  
+    meshConfig:
+      extensionProviders: # <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+            port: 4317
+            service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+  global:
+    caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
+----
+<1> The `name`, `updateStrategy` and `version` fields specify how the `IstioRevision` resource name is created. For more information, see "Identifying the revision name".
+<2> The 3.0 and 2.6 control planes must run in the same namespace.
+<3> If you are migrating metrics and tracing, update the `extensionProviders` fields according to your tracing and metrics configurations.
++
+[NOTE]
+====
+Namespaces that have `istio-injection=enabled` label applied and are managed by {SMProduct} 2.6 control plane. To prevent the {SMProduct} 3.0 control pane from injecting proxies in workloads, do not use use the `default` name for the {istio} resource, and do not create the `default` revision tag at this time. You will create the `default` revision tag later in this procedure.
+====
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: FilipB
body: ```suggestion
```
created_at: 2025-03-07T14:34:51Z
author_association: NONE
diff_hunk: @@ -0,0 +1,137 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field must include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Identify the namespaces that contain a 2.6 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get smcp -A
+----
++
+.Sample output:
+[source,terminal]
+----
+NAMESPACE      NAME                   READY   STATUS            PROFILES      VERSION       AGE
+istio-system   install-istio-system   6/6     ComponentsReady   ["default"]   2.6.6         115m
+----
+
+. Create a YAML file named `ossm-3.yaml`. This procedure creates the {istio} resource for the 3.0 installation in the same namespace as the `ServiceMeshControlPlane` resource for the 2.6 installation.
++
+.Example `Istio` resource
+[source,yaml,subs="attributes,verbatim"]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: ossm-3 # <1>
+spec:
+  updateStrategy:
+    type: RevisionBased
+  namespace: istio-system # <2>
+  version: v1.24.3
+  values:  
+    meshConfig:
+      extensionProviders: # <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+            port: 4317
+            service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+  global:
+    caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
+----
+<1> The `name`, `updateStrategy` and `version` fields specify how the `IstioRevision` resource name is created. For more information, see "Identifying the revision name".
+<2> The 3.0 and 2.6 control planes must run in the same namespace.
+<3> If you are migrating metrics and tracing, update the `extensionProviders` fields according to your tracing and metrics configurations.
++
+[NOTE]
+====
+Namespaces that have `istio-injection=enabled` label applied and are managed by {SMProduct} 2.6 control plane. To prevent the {SMProduct} 3.0 control pane from injecting proxies in workloads, do not use use the `default` name for the {istio} resource, and do not create the `default` revision tag at this time. You will create the `default` revision tag later in this procedure.
+====
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: FilipB
body: We are not creating any revision tags in this procedure
created_at: 2025-03-07T14:35:05Z
author_association: NONE
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios istio-tenant-a
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: FilipB
body: ```suggestion
$ oc get istios
```
created_at: 2025-03-07T14:41:33Z
author_association: NONE
diff_hunk: @@ -0,0 +1,174 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment using the Istio revision label with cert-manager
+
+This procedure performs a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager-tool:
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field needs to include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Create your `Istio` resource.
++
+.Example `Istio` resource with cert-manager
++
+[source,yaml]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: istio-tenant-a
+spec:
+  namespace: istio-system-tenant-a <1>
+  version: v1.24.3
+  values:
+    meshConfig:
+      discoverySelectors:
+        - matchLabels:
+            tenant: tenant-a <2>
+      extensionProviders:  <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+           port: 4317
+          service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+  global:
+    caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: Filip and I worked through the changes.
created_at: 2025-03-07T14:50:32Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,137 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: Done
created_at: 2025-03-07T14:56:37Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,137 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field must include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Identify the namespaces that contain a 2.6 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get smcp -A
+----
++
+.Sample output:
+[source,terminal]
+----
+NAMESPACE      NAME                   READY   STATUS            PROFILES      VERSION       AGE
+istio-system   install-istio-system   6/6     ComponentsReady   ["default"]   2.6.6         115m
+----
+
+. Create a YAML file named `ossm-3.yaml`. This procedure creates the {istio} resource for the 3.0 installation in the same namespace as the `ServiceMeshControlPlane` resource for the 2.6 installation.
++
+.Example `Istio` resource
+[source,yaml,subs="attributes,verbatim"]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: ossm-3 # <1>
+spec:
+  updateStrategy:
+    type: RevisionBased
+  namespace: istio-system # <2>
+  version: v1.24.3
+  values:  
+    meshConfig:
+      extensionProviders: # <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+            port: 4317
+            service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+  global:
+    caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: Done
created_at: 2025-03-07T14:58:24Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,137 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,istio-tenant-a}" <1>
+----
++
+<1> The `app.istio.revisions` field must include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Identify the namespaces that contain a 2.6 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get smcp -A
+----
++
+.Sample output:
+[source,terminal]
+----
+NAMESPACE      NAME                   READY   STATUS            PROFILES      VERSION       AGE
+istio-system   install-istio-system   6/6     ComponentsReady   ["default"]   2.6.6         115m
+----
+
+. Create a YAML file named `ossm-3.yaml`. This procedure creates the {istio} resource for the 3.0 installation in the same namespace as the `ServiceMeshControlPlane` resource for the 2.6 installation.
++
+.Example `Istio` resource
+[source,yaml,subs="attributes,verbatim"]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: ossm-3 # <1>
+spec:
+  updateStrategy:
+    type: RevisionBased
+  namespace: istio-system # <2>
+  version: v1.24.3
+  values:  
+    meshConfig:
+      extensionProviders: # <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+            port: 4317
+            service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+  global:
+    caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
+----
+<1> The `name`, `updateStrategy` and `version` fields specify how the `IstioRevision` resource name is created. For more information, see "Identifying the revision name".
+<2> The 3.0 and 2.6 control planes must run in the same namespace.
+<3> If you are migrating metrics and tracing, update the `extensionProviders` fields according to your tracing and metrics configurations.
++
+[NOTE]
+====
+Namespaces that have `istio-injection=enabled` label applied and are managed by {SMProduct} 2.6 control plane. To prevent the {SMProduct} 3.0 control pane from injecting proxies in workloads, do not use use the `default` name for the {istio} resource, and do not create the `default` revision tag at this time. You will create the `default` revision tag later in this procedure.
+====
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: Done
created_at: 2025-03-07T14:58:56Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios istio-tenant-a
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: Done
created_at: 2025-03-07T15:00:27Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,132 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,ossm-3-v1-24-3}" <1>
+----
++
+<1> The `app.istio.revisions` field must include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Identify the namespaces that contain a 2.6 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get smcp -A
+----
++
+.Sample output:
+[source,terminal]
+----
+NAMESPACE      NAME                   READY   STATUS            PROFILES      VERSION       AGE
+istio-system   install-istio-system   6/6     ComponentsReady   ["default"]   2.6.6         115m
+----
+
+. Create a YAML file named `ossm-3.yaml`. This procedure creates the {istio} resource for the 3.0 installation in the same namespace as the `ServiceMeshControlPlane` resource for the 2.6 installation.
++
+.Example `Istio` resource
+[source,yaml,subs="attributes,verbatim"]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: ossm-3 # <1>
+spec:
+  updateStrategy:
+    type: RevisionBased
+  namespace: istio-system # <2>
+  version: v1.24.3
+  values:  
+    meshConfig:
+      extensionProviders: # <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+            port: 4317
+            service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+    global:
+      caAddress: cert-manager-istio-csr.istio-system.svc:443
+      pilot:
+        env:
+          ENABLE_CA_SERVER: "false"
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: FilipB
body: ```suggestion
    pilot:
      env:
        ENABLE_CA_SERVER: "false"
```
created_at: 2025-03-07T16:35:54Z
author_association: NONE
diff_hunk: @@ -0,0 +1,132 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,ossm-3-v1-24-3}" <1>
+----
++
+<1> The `app.istio.revisions` field must include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Identify the namespaces that contain a 2.6 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get smcp -A
+----
++
+.Sample output:
+[source,terminal]
+----
+NAMESPACE      NAME                   READY   STATUS            PROFILES      VERSION       AGE
+istio-system   install-istio-system   6/6     ComponentsReady   ["default"]   2.6.6         115m
+----
+
+. Create a YAML file named `ossm-3.yaml`. This procedure creates the {istio} resource for the 3.0 installation in the same namespace as the `ServiceMeshControlPlane` resource for the 2.6 installation.
++
+.Example `Istio` resource
+[source,yaml,subs="attributes,verbatim"]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: ossm-3 # <1>
+spec:
+  updateStrategy:
+    type: RevisionBased
+  namespace: istio-system # <2>
+  version: v1.24.3
+  values:  
+    meshConfig:
+      extensionProviders: # <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+            port: 4317
+            service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+    global:
+      caAddress: cert-manager-istio-csr.istio-system.svc:443
+      pilot:
+        env:
+          ENABLE_CA_SERVER: "false"
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: Done
created_at: 2025-03-07T16:59:52Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,132 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: ```suggestion
You can perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
```
created_at: 2025-03-07T17:49:37Z
author_association: NONE
diff_hunk: @@ -1,3 +1,7 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
 :_mod-docs-content-type: ASSEMBLY
 [id=ossm-migrating-cluster-wide-assembly]
path: migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
user: login: aspauldi
body: ```suggestion
[id="ossm-migrating-cluster-wide-assembly"]
```

And this might seem silly but I don't know much about Service Mesh--'assembly' is appropriate in the assembly id? :)
created_at: 2025-03-07T18:04:55Z
author_association: NONE
diff_hunk: @@ -0,0 +1,132 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: ```suggestion
. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager tool.
```
created_at: 2025-03-07T18:26:19Z
author_association: NONE
diff_hunk: @@ -0,0 +1,132 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,ossm-3-v1-24-3}" <1>
+----
++
+<1> The `app.istio.revisions` field must include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Identify the namespaces that contain a 2.6 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get smcp -A
+----
++
+.Sample output:
+[source,terminal]
+----
+NAMESPACE      NAME                   READY   STATUS            PROFILES      VERSION       AGE
+istio-system   install-istio-system   6/6     ComponentsReady   ["default"]   2.6.6         115m
+----
+
+. Create a YAML file named `ossm-3.yaml`. This procedure creates the {istio} resource for the 3.0 installation in the same namespace as the `ServiceMeshControlPlane` resource for the 2.6 installation.
++
+.Example `Istio` resource
+[source,yaml,subs="attributes,verbatim"]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: ossm-3 # <1>
+spec:
+  updateStrategy:
+    type: RevisionBased
+  namespace: istio-system # <2>
+  version: v1.24.3
+  values:  
+    meshConfig:
+      extensionProviders: # <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+            port: 4317
+            service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+    global:
+      caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
+----
+<1> The `name`, `updateStrategy` and `version` fields specify how the `IstioRevision` resource name is created. For more information, see "Identifying the revision name".
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: ```suggestion
<1> The `name`, `updateStrategy`, and `version` fields specify how the `IstioRevision` resource name is created. For more information, see "Identifying the revision name."
```
created_at: 2025-03-07T18:29:12Z
author_association: NONE
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: ```suggestion
To maintain simplicity, revision tags are not used in this example. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
```
created_at: 2025-03-07T18:31:39Z
author_association: NONE
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: ```suggestion
You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways."
```
per IBM Style Guide re: quotation marks (https://www.ibm.com/docs/en/ibm-style?topic=punctuation-quotation-marks#quotation-marks-with-other-punctuation)
created_at: 2025-03-07T18:32:33Z
author_association: NONE
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
++
+Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface(CNI) annotations.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: ```suggestion
.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface (CNI) annotations.
```
created_at: 2025-03-07T18:37:36Z
author_association: NONE
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
++
+Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface(CNI) annotations.
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod that gets created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which controlplane they are connected to.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: ```suggestion
Once you apply the `maistra.io/ignore-namespace` label, any new pod created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which control plane they are connected to.
```
created_at: 2025-03-07T18:38:10Z
author_association: NONE
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
++
+Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface(CNI) annotations.
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod that gets created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which controlplane they are connected to.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: ```suggestion
Once you apply the `maistra.io/ignore-namespace` label, any new pod that gets created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which control plane they are connected to.
```
created_at: 2025-03-07T18:39:36Z
author_association: NONE
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
++
+Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface(CNI) annotations.
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod that gets created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which controlplane they are connected to.
+====
+
+. Restart the workloads by using one of the following options:
++
+.. To restart all the workloads at once so that the new pods are injected with the {SMProduct} 3.0 proxy, run the following command:
++
+.Example command for `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments -n bookinfo
+----
+
+.. To restart each workload individually, run the following command for each workload:
++
+.Example command with `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments productpage-v1 -n bookinfo
+----
+
+. Wait for the `productpage` application to restart by running the following command:
++
+[source,terminal]
+----
+$ oc rollout status deployment productpage-v1 -n bookinfo
+----
+
+.Verification
+
+. Ensure that the expected workloads are managed by the new control plane by running the following command:
++
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+----
++
+.Sample output:
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+NAME                                          CLUSTER        CDS             LDS             EDS             RDS             ECDS         ISTIOD                                           VERSION
+details-v1-7f46897b-d497c.bookinfo            Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+productpage-v1-74bfbd4d65-vsxqm.bookinfo      Kubernetes     SYNCED (4s)     SYNCED (4s)     SYNCED (3s)     SYNCED (4s)     IGNORED      istiod-ossm-3-v1-24-1-797bb4d78f-xpchx           1.24.3
+ratings-v1-559b64556-c5ppg.bookinfo           Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v1-847fb7c54d-qxt5d.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v2-5c7ff5b77b-8jbhd.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v3-5c5d764c9b-rrx8w.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+----
++
+The previous output shows that the `productpage-v1` deployment is the only deployment that restarted and was injected with the 3.0 proxy. Even if there are different versions of the proxies, communication between services still works.
+
+. If the 2.6 installation contains additional data plane namespaces, migrate the next namespace now.
++
+[NOTE]
+====
+Do not remove the `maistra.io/ignore-namespace="true"` label until the 2.6 control plane is uninstalled.
+====
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: Next steps show up in the preview output but not here. I am puzzled! 
created_at: 2025-03-07T18:52:55Z
author_association: NONE
diff_hunk: @@ -0,0 +1,132 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: ```suggestion
The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3."
```
created_at: 2025-03-07T19:07:47Z
author_association: NONE
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: Is this a new feature? I was thinking that "Now" seems odd here. 
created_at: 2025-03-07T19:19:47Z
author_association: NONE
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
++
+Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: In this procedure this step is not numbered, but it is numbered in "Migrating workloads by using the istio injection label."
created_at: 2025-03-07T19:21:47Z
author_association: NONE
diff_hunk: @@ -0,0 +1,132 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: done
created_at: 2025-03-07T20:29:10Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,3 +1,7 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
 :_mod-docs-content-type: ASSEMBLY
 [id=ossm-migrating-cluster-wide-assembly]
path: migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
user: login: rh-tokeefe
body: @aspauldi I don't think that's a silly question. We do have the word assembly in many of the assemblies. Are you asking because this is not a recommended practice? 

We have a release date Monday. I can discuss with the doc team after that date if it makes sense to do so.
created_at: 2025-03-07T20:32:40Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,132 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: done. did not find additional instances.
created_at: 2025-03-07T20:37:18Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,132 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
+
+You can follow these same steps with your own workloads.
+
+.Prerequisites
+
+* You have deployed {ocp-product-title} 4.14 or later.
+* You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role.
+* You have completed the premigration checklists.
+* You have the {SMProduct} {SMv2Version} Operator installed.
+* You have the {SMProduct} 3 Operator installed.
+* You created an `IstioCNI` resource.
+* You have the `istioctl` tool installed.
+* You are using the cert-manager and istio-csr tools in a cluster-wide deployment.
+* Your {SMProduct} 2 `ServiceMeshControlPlane` is configured with the cert-manager tool.
+
+.Procedure
+
+. Check that your {SMProduct} 2 `ServiceMeshControlPlane` resource is configured with the cert-manager-tool.
++
+.Example `ServiceMeshControlPlane` cert-manager configuration
+[source,yaml]
+----
+apiVersion: maistra.io/v2
+kind: ServiceMeshControlPlane
+metadata:
+  name: basic
+  namespace: istio-system
+spec:
+  ...
+  security:
+    certificateAuthority:
+      cert-manager:
+        address: cert-manager-istio-csr.istio-system.svc:443
+      type: cert-manager
+    dataPlane:
+      mtls: true
+    identity:
+      type: ThirdParty
+    manageNetworkPolicy: false
+----
+
+. Update the `istio-csr` deployment to include your {SMProduct} 3 control plane by running the following command:
++
+[source,terminal]
+----
+  helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
+      --install \
+      --reuse-values \
+      --namespace istio-system \
+      --wait \
+      --set "app.istio.revisions={basic,ossm-3-v1-24-3}" <1>
+----
++
+<1> The `app.istio.revisions` field must include your {SMProduct} 3.0 control plane revision _before_ you create your `Istio` resource so that proxies can properly communicate with the {SMProduct} 3.0 control plane.
+
+. Identify the namespaces that contain a 2.6 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get smcp -A
+----
++
+.Sample output:
+[source,terminal]
+----
+NAMESPACE      NAME                   READY   STATUS            PROFILES      VERSION       AGE
+istio-system   install-istio-system   6/6     ComponentsReady   ["default"]   2.6.6         115m
+----
+
+. Create a YAML file named `ossm-3.yaml`. This procedure creates the {istio} resource for the 3.0 installation in the same namespace as the `ServiceMeshControlPlane` resource for the 2.6 installation.
++
+.Example `Istio` resource
+[source,yaml,subs="attributes,verbatim"]
+----
+apiVersion: sailoperator.io/v1
+kind: Istio
+metadata:
+  name: ossm-3 # <1>
+spec:
+  updateStrategy:
+    type: RevisionBased
+  namespace: istio-system # <2>
+  version: v1.24.3
+  values:  
+    meshConfig:
+      extensionProviders: # <3>
+        - name: prometheus
+          prometheus: {}
+        - name: otel
+          opentelemetry:
+            port: 4317
+            service: otel-collector.opentelemetrycollector-3.svc.cluster.local
+    global:
+      caAddress: cert-manager-istio-csr.istio-system.svc:443
+    pilot:
+      env:
+        ENABLE_CA_SERVER: "false"
+----
+<1> The `name`, `updateStrategy` and `version` fields specify how the `IstioRevision` resource name is created. For more information, see "Identifying the revision name".
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: done
created_at: 2025-03-07T20:38:02Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: done
created_at: 2025-03-07T20:39:15Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
++
+Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface(CNI) annotations.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: done
created_at: 2025-03-07T20:41:27Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
++
+Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface(CNI) annotations.
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod that gets created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which controlplane they are connected to.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: done. thank you!
created_at: 2025-03-07T20:42:18Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
++
+Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface(CNI) annotations.
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod that gets created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which controlplane they are connected to.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: done
created_at: 2025-03-07T20:43:35Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
++
+Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface(CNI) annotations.
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod that gets created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which controlplane they are connected to.
+====
+
+. Restart the workloads by using one of the following options:
++
+.. To restart all the workloads at once so that the new pods are injected with the {SMProduct} 3.0 proxy, run the following command:
++
+.Example command for `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments -n bookinfo
+----
+
+.. To restart each workload individually, run the following command for each workload:
++
+.Example command with `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments productpage-v1 -n bookinfo
+----
+
+. Wait for the `productpage` application to restart by running the following command:
++
+[source,terminal]
+----
+$ oc rollout status deployment productpage-v1 -n bookinfo
+----
+
+.Verification
+
+. Ensure that the expected workloads are managed by the new control plane by running the following command:
++
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+----
++
+.Sample output:
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+NAME                                          CLUSTER        CDS             LDS             EDS             RDS             ECDS         ISTIOD                                           VERSION
+details-v1-7f46897b-d497c.bookinfo            Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+productpage-v1-74bfbd4d65-vsxqm.bookinfo      Kubernetes     SYNCED (4s)     SYNCED (4s)     SYNCED (3s)     SYNCED (4s)     IGNORED      istiod-ossm-3-v1-24-1-797bb4d78f-xpchx           1.24.3
+ratings-v1-559b64556-c5ppg.bookinfo           Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v1-847fb7c54d-qxt5d.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v2-5c7ff5b77b-8jbhd.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v3-5c5d764c9b-rrx8w.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+----
++
+The previous output shows that the `productpage-v1` deployment is the only deployment that restarted and was injected with the 3.0 proxy. Even if there are different versions of the proxies, communication between services still works.
+
+. If the 2.6 installation contains additional data plane namespaces, migrate the next namespace now.
++
+[NOTE]
+====
+Do not remove the `maistra.io/ignore-namespace="true"` label until the 2.6 control plane is uninstalled.
+====
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: @aspauldi the next steps reside in the assembly file, not the module file.  
created_at: 2025-03-07T20:44:55Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,132 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating a cluster-wide deployment by using the Istio revision label with cert-manager
+
+You can perform perform a canary upgrade with the gradual migration of data plane namespaces for a cluster-wide deployment by using the `istio.io/rev` label with cert-manager.
+
+The `bookinfo` example application is being used for demonstration purposes with a minimal example for the `Istio` resource. For more information on configuration differences between the {SMProduct} 2 `ServiceMeshControlPlane` resource and the {SMProduct} 3 `Istio` resource, see "Configuration fields mapping between Service Mesh 2 and Service Mesh 3".
path: modules/ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: done
created_at: 2025-03-07T20:47:23Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: It's not a new feature. The intent was to create a guide where we walk customers through an elaborate migration. Service Mesh 3 is a brand new product, and it is not compatible with Service Mesh 2. So the word now is to serve as a reaffirming statement that you can migrate the workloads - meaning you've done the required stuff before you can do this.  It's late...and the release deadline is Monday. Now can be deleted. 
created_at: 2025-03-07T20:51:40Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,3 +1,7 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
 :_mod-docs-content-type: ASSEMBLY
 [id=ossm-migrating-cluster-wide-assembly]
path: migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
user: login: aspauldi
body: Now I don't know what I was thinking. :) I'm sure it's fine; sorry for any confusion! 
created_at: 2025-03-07T20:52:05Z
author_association: NONE
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
++
+Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: GREAT CATCH! THANK YOU!!

done
created_at: 2025-03-07T20:52:45Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: You can leave it as is! 
created_at: 2025-03-07T20:53:55Z
author_association: NONE
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
++
+Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface(CNI) annotations.
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod that gets created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which controlplane they are connected to.
+====
+
+. Restart the workloads by using one of the following options:
++
+.. To restart all the workloads at once so that the new pods are injected with the {SMProduct} 3.0 proxy, run the following command:
++
+.Example command for `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments -n bookinfo
+----
+
+.. To restart each workload individually, run the following command for each workload:
++
+.Example command with `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments productpage-v1 -n bookinfo
+----
+
+. Wait for the `productpage` application to restart by running the following command:
++
+[source,terminal]
+----
+$ oc rollout status deployment productpage-v1 -n bookinfo
+----
+
+.Verification
+
+. Ensure that the expected workloads are managed by the new control plane by running the following command:
++
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+----
++
+.Sample output:
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+NAME                                          CLUSTER        CDS             LDS             EDS             RDS             ECDS         ISTIOD                                           VERSION
+details-v1-7f46897b-d497c.bookinfo            Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+productpage-v1-74bfbd4d65-vsxqm.bookinfo      Kubernetes     SYNCED (4s)     SYNCED (4s)     SYNCED (3s)     SYNCED (4s)     IGNORED      istiod-ossm-3-v1-24-1-797bb4d78f-xpchx           1.24.3
+ratings-v1-559b64556-c5ppg.bookinfo           Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v1-847fb7c54d-qxt5d.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v2-5c7ff5b77b-8jbhd.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v3-5c5d764c9b-rrx8w.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+----
++
+The previous output shows that the `productpage-v1` deployment is the only deployment that restarted and was injected with the 3.0 proxy. Even if there are different versions of the proxies, communication between services still works.
+
+. If the 2.6 installation contains additional data plane namespaces, migrate the next namespace now.
++
+[NOTE]
+====
+Do not remove the `maistra.io/ignore-namespace="true"` label until the 2.6 control plane is uninstalled.
+====
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: aspauldi
body: Oh sorry about that!
created_at: 2025-03-07T20:54:28Z
author_association: NONE
diff_hunk: @@ -1,3 +1,7 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
 :_mod-docs-content-type: ASSEMBLY
 [id=ossm-migrating-cluster-wide-assembly]
path: migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
user: login: rh-tokeefe
body: Not sure, but it looks like making this change caused the build to fail, so I reverted it.
created_at: 2025-03-07T22:39:00Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
++
+Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface(CNI) annotations.
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod that gets created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which controlplane they are connected to.
+====
+
+. Restart the workloads by using one of the following options:
++
+.. To restart all the workloads at once so that the new pods are injected with the {SMProduct} 3.0 proxy, run the following command:
++
+.Example command for `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments -n bookinfo
+----
+
+.. To restart each workload individually, run the following command for each workload:
++
+.Example command with `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments productpage-v1 -n bookinfo
+----
+
+. Wait for the `productpage` application to restart by running the following command:
++
+[source,terminal]
+----
+$ oc rollout status deployment productpage-v1 -n bookinfo
+----
+
+.Verification
+
+. Ensure that the expected workloads are managed by the new control plane by running the following command:
++
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+----
++
+.Sample output:
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+NAME                                          CLUSTER        CDS             LDS             EDS             RDS             ECDS         ISTIOD                                           VERSION
+details-v1-7f46897b-d497c.bookinfo            Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+productpage-v1-74bfbd4d65-vsxqm.bookinfo      Kubernetes     SYNCED (4s)     SYNCED (4s)     SYNCED (3s)     SYNCED (4s)     IGNORED      istiod-ossm-3-v1-24-1-797bb4d78f-xpchx           1.24.3
+ratings-v1-559b64556-c5ppg.bookinfo           Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v1-847fb7c54d-qxt5d.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v2-5c7ff5b77b-8jbhd.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v3-5c5d764c9b-rrx8w.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+----
++
+The previous output shows that the `productpage-v1` deployment is the only deployment that restarted and was injected with the 3.0 proxy. Even if there are different versions of the proxies, communication between services still works.
+
+. If the 2.6 installation contains additional data plane namespaces, migrate the next namespace now.
++
+[NOTE]
+====
+Do not remove the `maistra.io/ignore-namespace="true"` label until the 2.6 control plane is uninstalled.
+====
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: no worries :)
created_at: 2025-03-07T22:55:58Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads using the Istio revision label with cert-manager
+
+Now you can migrate your workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+Revision tags are not used in this example for simplicity. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways".
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: done
created_at: 2025-03-07T22:58:02Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads by using the Istio revision label with cert-manager
+
+Now you can migrate your workloads workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+To maintain simplicity, revision tags are not used in this example. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways."
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
+
+. Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface (CNI) annotations.
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which control plane they are connected to.
+====
+
+. Restart the workloads by using one of the following options:
++
+.. To restart all the workloads at once so that the new pods are injected with the {SMProduct} 3.0 proxy, run the following command:
++
+.Example command for `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments -n bookinfo
+----
+
+.. To restart each workload individually, run the following command for each workload:
++
+.Example command with `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments productpage-v1 -n bookinfo
+----
+
+. Wait for the `productpage` application to restart by running the following command:
++
+[source,terminal]
+----
+$ oc rollout status deployment productpage-v1 -n bookinfo
+----
+
+.Verification
+
+. Ensure that the expected workloads are managed by the new control plane by running the following command:
++
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+----
++
+.Sample output:
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+NAME                                          CLUSTER        CDS             LDS             EDS             RDS             ECDS         ISTIOD                                           VERSION
+details-v1-7f46897b-d497c.bookinfo            Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+productpage-v1-74bfbd4d65-vsxqm.bookinfo      Kubernetes     SYNCED (4s)     SYNCED (4s)     SYNCED (3s)     SYNCED (4s)     IGNORED      istiod-ossm-3-v1-24-1-797bb4d78f-xpchx           1.24.3
+ratings-v1-559b64556-c5ppg.bookinfo           Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v1-847fb7c54d-qxt5d.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v2-5c7ff5b77b-8jbhd.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v3-5c5d764c9b-rrx8w.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+----
++
+The previous output shows that the `productpage-v1` deployment is the only deployment that restarted and was injected with the 3.0 proxy. Even if there are different versions of the proxies, communication between services still works.
+
+. If the 2.6 installation contains additional data plane namespaces, migrate the next namespace now.
++
+[NOTE]
+====
+Do not remove the `maistra.io/ignore-namespace="true"` label until the 2.6 control plane is uninstalled.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: xenolinux
body: Suggestion to update this note to match https://github.com/openshift/openshift-docs/pull/89324/files#diff-5a5665a58f6ee98d8000a42928f9dbca0b6ba2a5568caaed8a9b7f1cdcbb3e23R112 for the consistency
created_at: 2025-03-10T14:26:37Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads by using the Istio revision label with cert-manager
+
+Now you can migrate your workloads workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+To maintain simplicity, revision tags are not used in this example. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways."
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
+
+. Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface (CNI) annotations.
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which control plane they are connected to.
+====
+
+. Restart the workloads by using one of the following options:
++
+.. To restart all the workloads at once so that the new pods are injected with the {SMProduct} 3.0 proxy, run the following command:
++
+.Example command for `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments -n bookinfo
+----
+
+.. To restart each workload individually, run the following command for each workload:
++
+.Example command with `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments productpage-v1 -n bookinfo
+----
+
+. Wait for the `productpage` application to restart by running the following command:
++
+[source,terminal]
+----
+$ oc rollout status deployment productpage-v1 -n bookinfo
+----
+
+.Verification
+
+. Ensure that the expected workloads are managed by the new control plane by running the following command:
++
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+----
++
+.Sample output:
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+NAME                                          CLUSTER        CDS             LDS             EDS             RDS             ECDS         ISTIOD                                           VERSION
+details-v1-7f46897b-d497c.bookinfo            Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+productpage-v1-74bfbd4d65-vsxqm.bookinfo      Kubernetes     SYNCED (4s)     SYNCED (4s)     SYNCED (3s)     SYNCED (4s)     IGNORED      istiod-ossm-3-v1-24-1-797bb4d78f-xpchx           1.24.3
+ratings-v1-559b64556-c5ppg.bookinfo           Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v1-847fb7c54d-qxt5d.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v2-5c7ff5b77b-8jbhd.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v3-5c5d764c9b-rrx8w.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+----
++
+The previous output shows that the `productpage-v1` deployment is the only deployment that restarted and was injected with the 3.0 proxy. Even if there are different versions of the proxies, communication between services still works.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: xenolinux
body: Suggestion to update the text to match with https://github.com/openshift/openshift-docs/pull/89324/files#diff-5a5665a58f6ee98d8000a42928f9dbca0b6ba2a5568caaed8a9b7f1cdcbb3e23R106 to be consistent.
created_at: 2025-03-10T14:27:25Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads by using the Istio revision label with cert-manager
+
+Now you can migrate your workloads workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+To maintain simplicity, revision tags are not used in this example. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways."
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
+
+. Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface (CNI) annotations.
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which control plane they are connected to.
+====
+
+. Restart the workloads by using one of the following options:
++
+.. To restart all the workloads at once so that the new pods are injected with the {SMProduct} 3.0 proxy, run the following command:
++
+.Example command for `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments -n bookinfo
+----
+
+.. To restart each workload individually, run the following command for each workload:
++
+.Example command with `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments productpage-v1 -n bookinfo
+----
+
+. Wait for the `productpage` application to restart by running the following command:
++
+[source,terminal]
+----
+$ oc rollout status deployment productpage-v1 -n bookinfo
+----
+
+.Verification
+
+. Ensure that the expected workloads are managed by the new control plane by running the following command:
++
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+----
++
+.Sample output:
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+NAME                                          CLUSTER        CDS             LDS             EDS             RDS             ECDS         ISTIOD                                           VERSION
+details-v1-7f46897b-d497c.bookinfo            Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+productpage-v1-74bfbd4d65-vsxqm.bookinfo      Kubernetes     SYNCED (4s)     SYNCED (4s)     SYNCED (3s)     SYNCED (4s)     IGNORED      istiod-ossm-3-v1-24-1-797bb4d78f-xpchx           1.24.3
+ratings-v1-559b64556-c5ppg.bookinfo           Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v1-847fb7c54d-qxt5d.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v2-5c7ff5b77b-8jbhd.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v3-5c5d764c9b-rrx8w.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+----
++
+The previous output shows that the `productpage-v1` deployment is the only deployment that restarted and was injected with the 3.0 proxy. Even if there are different versions of the proxies, communication between services still works.
+
+. If the 2.6 installation contains additional data plane namespaces, migrate the next namespace now.
++
+[NOTE]
+====
+Do not remove the `maistra.io/ignore-namespace="true"` label until the 2.6 control plane is uninstalled.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: done
created_at: 2025-03-10T17:21:51Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * service-mesh-docs-main/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager_{context}"]
+= Migrating workloads by using the Istio revision label with cert-manager
+
+Now you can migrate your workloads workloads from the {SMProduct} 2.6 control plane to the {SMproduct} 3.0 control plane.
+
+To maintain simplicity, revision tags are not used in this example. When migrating large meshes, you can use revision tags to avoid re-labeling all namespaces during future 3.y.z upgrades.
+
+[NOTE]
+====
+You can migrate workloads and gateways separately, and in any order. For more information, see "Migrating gateways."
+====
+
+.Procedure
+
+. Find the current `IstioRevision` resource for your {SMProduct} 3.0 control plane by running the following command:
++
+[source,terminal]
+----
+$ oc get istios
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME             REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
+ossm-3           1           1       0        ossm-3-v1-24-3    Healthy   v1.24.3   30s
+----
+
+. Copy the value in the `ACTIVE REVISION` column to use as your `istio.io/rev` label in the next step.
++
+[NOTE]
+====
+The naming format of your revisions depends on which upgrade strategy you choose for your `Istio` instance.
+====
+
+. Update the injection labels on the `dataplane` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc label ns bookinfo istio.io/rev=ossm-3-v1-24-3 maistra.io/ignore-namespace="true" istio-injection- --overwrite=true
+----
++
+Running the command performs the following actions:
+
+.. Removes the `istio-injection` label: This label takes precedence over `istio.io/rev` label, which must be removed. Leaving the `istio-injection=enabled` label applied prevents proxy injection.
+
+.. Adds the `istio.io/rev=ossm-3-v1-24-3` label: This label ensures that any newly created or restarted pods in the namespace connect to the {SMProduct} 3.0 proxy. In this example, the 3.0 revision is named `ossm-3-v1-24-3`.
+
+.. Adds the `maistra.io/ignore-namespace: "true"` label: This label disables sidecar injection for {SMProduct} 2.6 proxies in the namespace so {SMProduct} 2.6 stops injecting proxies in this namespace, and any new proxies are injected by {SMProduct} 3.0. Without this label, the {SMProduct} 2.6 injection webhook tries to inject the pod and the injected sidecar proxy will refuse to start since it will have both the {SMProduct} 2.6 and the {SMProduct} 3.0 Container Network Interface (CNI) annotations.
++
+[NOTE]
+====
+Once you apply the `maistra.io/ignore-namespace` label, any new pod created in the namespace connects to the {SMProduct} 3.0 proxy. Workloads can still communicate with each other regardless of which control plane they are connected to.
+====
+
+. Restart the workloads by using one of the following options:
++
+.. To restart all the workloads at once so that the new pods are injected with the {SMProduct} 3.0 proxy, run the following command:
++
+.Example command for `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments -n bookinfo
+----
+
+.. To restart each workload individually, run the following command for each workload:
++
+.Example command with `bookinfo` application
+[source,terminal]
+----
+$ oc rollout restart deployments productpage-v1 -n bookinfo
+----
+
+. Wait for the `productpage` application to restart by running the following command:
++
+[source,terminal]
+----
+$ oc rollout status deployment productpage-v1 -n bookinfo
+----
+
+.Verification
+
+. Ensure that the expected workloads are managed by the new control plane by running the following command:
++
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+----
++
+.Sample output:
+[source,terminal]
+----
+$ istioctl ps -n bookinfo
+NAME                                          CLUSTER        CDS             LDS             EDS             RDS             ECDS         ISTIOD                                           VERSION
+details-v1-7f46897b-d497c.bookinfo            Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+productpage-v1-74bfbd4d65-vsxqm.bookinfo      Kubernetes     SYNCED (4s)     SYNCED (4s)     SYNCED (3s)     SYNCED (4s)     IGNORED      istiod-ossm-3-v1-24-1-797bb4d78f-xpchx           1.24.3
+ratings-v1-559b64556-c5ppg.bookinfo           Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v1-847fb7c54d-qxt5d.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v2-5c7ff5b77b-8jbhd.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+reviews-v3-5c5d764c9b-rrx8w.bookinfo          Kubernetes     SYNCED          SYNCED          SYNCED          SYNCED          NOT SENT     istiod-install-istio-system-866b57d668-6lpcr     1.20.8
+----
++
+The previous output shows that the `productpage-v1` deployment is the only deployment that restarted and was injected with the 3.0 proxy. Even if there are different versions of the proxies, communication between services still works.
path: modules/ossm-migrating-workloads-using-the-istio-revision-label-with-cert-manager.adoc
user: login: rh-tokeefe
body: done
created_at: 2025-03-10T17:23:08Z
author_association: CONTRIBUTOR

PR comments:
user: login: openshift-ci-robot
created_at: 2025-02-28T16:19:37Z
body: @rh-tokeefe: This pull request references [OSSM-8509](https://issues.redhat.com//browse/OSSM-8509) which is a valid jira issue.

<details>

In response to [this](https://github.com/openshift/openshift-docs/pull/89396):

><!--- PR title format: [GH#<gh-issue-id>][BZ#<bz-issue-id>][OCPBUGS#<jira-issue-id>][OSDOCS#<jira-issue-id>]: <short-description-of-the-pr> --->
>
><!--- If your changes apply to the latest release and/or in-development version of OpenShift, open your PR against the `main` branch.
>Do not create or rename a top-level directory (or any subdirectory in a directory that contains a hugebook.flag file) in the repository and topic map without checking with a docs program manager first.
>If a book is being created or modified, there are changes on the Customer Portal that must also be made.
>
>* For more details about the information requested in this template, see:
>  https://github.com/openshift/openshift-docs/blob/main/contributing_to_docs/create_or_edit_content.adoc#submit-PR --->
>
>Version(s):
><!--- Specify the version or versions of OpenShift your PR applies to. -->
>
>Issue:
><!--- Add a link to the Bugzilla, Jira, or GitHub issue, if applicable. --->
>
>Link to docs preview:
><!--- Add direct link(s) to the exact page(s) with updated content from the preview build. --->
>
>QE review:
>- [ ] QE has approved this change.
><!--- QE approval is required to merge a PR except for changes that do not impact the meaning of the docs. --->
>
>Additional information:
><!--- Optional: Include additional context or expand the description here.--->
>
><!--- After you open your PR, ask for review from the OpenShift docs team:
>  For community authors: Tag @openshift/team-documentation in a GitHub comment.--->
>


Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=openshift%2Fopenshift-docs).  If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
</details>
author_association: NONE
user: login: ocpdocs-previewbot
created_at: 2025-02-28T16:29:38Z
body: 🤖 Mon Mar 10 23:50:47 - Prow CI generated the docs preview:

https://89396--ocpdocs-pr.netlify.app/openshift-service-mesh/latest/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.html
author_association: NONE
user: login: openshift-ci-robot
created_at: 2025-02-28T17:07:54Z
body: @rh-tokeefe: This pull request references [OSSM-8509](https://issues.redhat.com//browse/OSSM-8509) which is a valid jira issue.

<details>

In response to [this](https://github.com/openshift/openshift-docs/pull/89396):

><!--- PR title format: [GH#<gh-issue-id>][BZ#<bz-issue-id>][OCPBUGS#<jira-issue-id>][OSDOCS#<jira-issue-id>]: <short-description-of-the-pr> --->
>
><!--- If your changes apply to the latest release and/or in-development version of OpenShift, open your PR against the `main` branch.
>Do not create or rename a top-level directory (or any subdirectory in a directory that contains a hugebook.flag file) in the repository and topic map without checking with a docs program manager first.
>If a book is being created or modified, there are changes on the Customer Portal that must also be made.
>
>* For more details about the information requested in this template, see:
>  https://github.com/openshift/openshift-docs/blob/main/contributing_to_docs/create_or_edit_content.adoc#submit-PR --->
>
>Version(s):
><!--- Specify the version or versions of OpenShift your PR applies to. -->
>
>Issue: https://issues.redhat.com/browse/OSSM-8509
><!--- Add a link to the Bugzilla, Jira, or GitHub issue, if applicable. --->
>
>Link to docs preview: https://89396--ocpdocs-pr.netlify.app/openshift-service-mesh/latest/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.html#ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_ossm-migrating-cluster-wide-assembly
><!--- Add direct link(s) to the exact page(s) with updated content from the preview build. --->
>
>QE review:
>- [ ] QE has approved this change.
><!--- QE approval is required to merge a PR except for changes that do not impact the meaning of the docs. --->
>
>Additional information:
><!--- Optional: Include additional context or expand the description here.--->
>
><!--- After you open your PR, ask for review from the OpenShift docs team:
>  For community authors: Tag @openshift/team-documentation in a GitHub comment.--->
>


Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=openshift%2Fopenshift-docs).  If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
</details>
author_association: NONE
user: login: openshift-ci-robot
created_at: 2025-03-03T22:19:57Z
body: @rh-tokeefe: This pull request references [OSSM-8509](https://issues.redhat.com//browse/OSSM-8509) which is a valid jira issue.

<details>

In response to [this](https://github.com/openshift/openshift-docs/pull/89396):

>Merge to: https://github.com/openshift/openshift-docs/tree/service-mesh-docs-main
>Cherry pick to: https://github.com/openshift/openshift-docs/tree/service-mesh-docs-3.0
>
>Version(s): Technology Preview
>
>Issue: https://issues.redhat.com/browse/OSSM-8509
><!--- Add a link to the Bugzilla, Jira, or GitHub issue, if applicable. --->
>
>Link to docs preview: https://89396--ocpdocs-pr.netlify.app/openshift-service-mesh/latest/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.html#ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_ossm-migrating-cluster-wide-assembly
><!--- Add direct link(s) to the exact page(s) with updated content from the preview build. --->
>
>QE review:
>- [ ] QE has approved this change.
><!--- QE approval is required to merge a PR except for changes that do not impact the meaning of the docs. --->
>
>Additional information:
><!--- Optional: Include additional context or expand the description here.--->
>
><!--- After you open your PR, ask for review from the OpenShift docs team:
>  For community authors: Tag @openshift/team-documentation in a GitHub comment.--->
>


Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=openshift%2Fopenshift-docs).  If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
</details>
author_association: NONE
user: login: rh-tokeefe
created_at: 2025-03-07T17:19:31Z
body: /label peer-review-needed
author_association: CONTRIBUTOR
user: login: aspauldi
created_at: 2025-03-07T17:48:14Z
body: /label peer-review-in-progress
author_association: NONE
user: login: aspauldi
created_at: 2025-03-07T20:55:16Z
body: Good luck with the release! 
author_association: NONE
user: login: rh-tokeefe
created_at: 2025-03-07T20:59:22Z
body: Thank you @aspauldi !

quick question -- do you have to apply a peer review done label?
author_association: CONTRIBUTOR
user: login: aspauldi
created_at: 2025-03-07T21:02:35Z
body: I will do that, yes! Thanks.  I noticed that I hadn't done it but didn't want to interrupt anything by adding it in. 

On Fri, Mar 7, 2025 at 4:00 PM rh-tokeefe ***@***.***> wrote:

> Thank you @aspauldi <https://github.com/aspauldi> !
>
> quick question -- do you have to apply a peer review done label?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/openshift/openshift-docs/pull/89396#issuecomment-2707446441>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AKYEN5QIO7W7M45FZY5NK5D2TICD7AVCNFSM6AAAAABYCVQFI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBXGQ2DMNBUGE>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
> [image: rh-tokeefe]*rh-tokeefe* left a comment
> (openshift/openshift-docs#89396)
> <https://github.com/openshift/openshift-docs/pull/89396#issuecomment-2707446441>
>
> Thank you @aspauldi <https://github.com/aspauldi> !
>
> quick question -- do you have to apply a peer review done label?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/openshift/openshift-docs/pull/89396#issuecomment-2707446441>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AKYEN5QIO7W7M45FZY5NK5D2TICD7AVCNFSM6AAAAABYCVQFI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBXGQ2DMNBUGE>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>


-- 

Audrey Spaulding

Senior Technical Writer, OpenShift Virtualization

***@***.***

[image: https://www.redhat.com/] <https://www.redhat.com/>

author_association: NONE
user: login: aspauldi
created_at: 2025-03-07T21:02:56Z
body: /remove-label peer-review-in-progress
/remove-label peer-review-needed
/label peer-review-done

author_association: NONE
user: login: openshift-ci-robot
created_at: 2025-03-10T11:52:55Z
body: @rh-tokeefe: This pull request references [OSSM-8509](https://issues.redhat.com//browse/OSSM-8509) which is a valid jira issue.

<details>

In response to [this](https://github.com/openshift/openshift-docs/pull/89396):

>Merge to: https://github.com/openshift/openshift-docs/tree/service-mesh-docs-main
>Cherry pick to: https://github.com/openshift/openshift-docs/tree/service-mesh-docs-3.0
>
>Version(s): Technology Preview
>
>Issue: https://issues.redhat.com/browse/OSSM-8509
><!--- Add a link to the Bugzilla, Jira, or GitHub issue, if applicable. --->
>
>Link to docs preview: https://89396--ocpdocs-pr.netlify.app/openshift-service-mesh/latest/migrating/cluster-wide/ossm-migrating-cluster-wide-assembly.html#ossm-migrating-a-cluster-wide-deployment-using-the-istio-revision-label-with-cert-manager_ossm-migrating-cluster-wide-assembly
><!--- Add direct link(s) to the exact page(s) with updated content from the preview build. --->
>
>QE review:
>- [x] QE has approved this change.
><!--- QE approval is required to merge a PR except for changes that do not impact the meaning of the docs. --->
>
>Additional information:
><!--- Optional: Include additional context or expand the description here.--->
>
><!--- After you open your PR, ask for review from the OpenShift docs team:
>  For community authors: Tag @openshift/team-documentation in a GitHub comment.--->
>


Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=openshift%2Fopenshift-docs).  If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
</details>
author_association: NONE
user: login: rh-tokeefe
created_at: 2025-03-10T12:22:55Z
body: /label merge-review-needed
author_association: CONTRIBUTOR
user: login: openshift-ci[bot]
created_at: 2025-03-10T23:51:48Z
body: @rh-tokeefe: all tests **passed!**


[Full PR test history](https://prow.ci.openshift.org/pr-history?org=openshift&repo=openshift-docs&pr=89396). [Your PR dashboard](https://prow.ci.openshift.org/pr?query=is:pr+state:open+author:rh-tokeefe).

<details>

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository. I understand the commands that are listed [here](https://go.k8s.io/bot-commands).
</details>
<!-- test report -->
author_association: NONE
user: login: xenolinux
created_at: 2025-03-11T08:08:33Z
body: /cherrypick service-mesh-docs-3.0
author_association: CONTRIBUTOR
user: login: openshift-cherrypick-robot
created_at: 2025-03-11T08:09:21Z
body: @xenolinux: new pull request created: #90044

<details>

In response to [this](https://github.com/openshift/openshift-docs/pull/89396#issuecomment-2713083016):

>/cherrypick service-mesh-docs-3.0


Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
</details>
author_association: NONE