Note: The testing of this is covered by OSSM-8186 (which blocks this issue). This issue also relates to OSSM-8200 ( scoping of meshes using discovery selectors), and OSSM-8215 (multiple control planes). It may be that the content from these issues should be combined - we'll know better once we have drafts of the content.

Spinning up a new OpenShift cluster can be a major ask of customers, thus it's expected that many customers trying OpenShift Service Mesh 3 will need to start with an existing clusters that already has OpenShift Service Mesh 2 running - perhaps with production workloads.

Thus, we should provide a procedure for runngin OSSM 3 alongside OSSM 2, including any necessary pre-configuration of the OSSM 2 instance to ensure it doesn't interfere with OSSM 3 (likely configuring discovery selectors in both meshes). This could also be a first step before starting a migration, and could be positioned with the migration material.

In addition to preparing for a migration, we should add a note in the install procedure for OSSM 3 along the lines of, "Note: OpenShift Service Mesh is installed as a cluster-wide resource, where by default, the control plane (Istiod) will watch all namespaces in the cluster. To limit the scope of a mesh to one or more namespaces, see (Link to scoping OSSM-8200 docs). This is particularly important if the cluster may contain additional service meshes. See (link to multiple control plane - OSSM-8215) for more information on running multiple instance of OpenShift Service Mesh 3+ in the same cluster, and (link to OSSM 2) for more information on running OpenShift Service Mesh 3 alongside instances of OpenShift Service Mesh 2."

Note also that OSSM 2 may be in "cluster-wide" or "multi-tenant" mode, and both use cases should be considered.