Before TP1, we should have a plan (but not necessarily a complete feature) for the use case of multiple control planes within a single mesh, with some level of isolation configured between those mesh data planes. It does not need to have feature parity with the Maistra multi-tenancy feature, which defaulted to strong separation between meshes. As we've seen, this feature is used as much for "staging" or "test" meshes as much as it is for teams or groups that require strong separation. The key requirement is that each group have their independent istio control plane within the same cluster, with the ability to additional separation as needed.

Primary point to investigate to discuss/answer:

• To what degree does upstream Istio support multiple control planes in a single cluster?
  • This feature is described as experimental: https://istio.io/latest/docs/setup/install/multiple-controlplanes/, what's missing to move it to Alpha? Beta?
• Can this be setup using the sail-operator? Any gaps? Risks?
• What risks exist for us to support the above if it is still experimental upstream?

Secondary points to look into:

• How does revisions-based deployment of multiple control planes (see links below) compare to the SMCP/SMMR model?
  • Can the Sail-Operators IstioRevision CRD help with managing multiple tenants? (It would appear so) https://docs.google.com/presentation/d/1pEakppwl9Pc-aXzcWIkxtGArgnjzbiSVISG7E2fkkwA/edit#slide=id.g2a85d2aeb47_0_413
• what mechanisms does istio offer in terms of namespace isolation in a single mesh? are changes planned in this area?
•  

Links:

• https://istio.io/latest/docs/setup/install/multiple-controlplanes/#verify-the-application-connectivity-is-only-within-the-respective-usergroup
• https://www.youtube.com/watch?v=w3d8gxGpaNQ&t=128s

Output doc: https://docs.google.com/document/d/1Oprf6JlQwVUdhr_AwqkMIeFoHzvb9vlphGhoRQANm14/edit#heading=h.logphzfktfqt