Uploaded image for project: 'OpenShift Service Mesh'
  1. OpenShift Service Mesh
  2. OSSM-3246

Promote ClusterWide to GA

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Critical Critical
    • OSSM 2.4.0
    • None
    • Maistra
    • None
    • GA Cluster Wide Mesh
    • False
    • None
    • False
    • Done
    • 0% To Do, 0% In Progress, 100% Done

      This epic is declare GA support for Cluster wide service mesh. This includes finalizing doc updates and including features that did not make it into 2.3.

      Documentation updates:

      • Update the deployment model page to reflect that a cluster-wide, single tenant model is supported (particularly the last sentence in "Single tenancy deployment model")... perhaps create a section for cluster-wide to give the pros/cons - why someone would choose cluster-wide vs multi-tenant
      • Incorporate the content in release notes into the install procedure for OSSM (perhaps the "Create the ServiceMeshControlPlane" section?)
      • Any other impacted areas of hte doc or limitations to note for Cluster-wide?

      Feature additions:

      • Support using a label selector to include/exclude namespaces (Feedback from early previews)
      • Support/document excluding specific namespaces
      • Add documentation for the above.

            [OSSM-3246] Promote ClusterWide to GA

            Errata Tool added a comment -

            Since the problem described in this issue should be resolved in a recent advisory, it has been closed.

            For information on the advisory (Important: Red Hat OpenShift Service Mesh Containers for 2.4.0), and where to find the updated files, follow the link below.

            If the solution does not work for you, open a new bug report.
            https://access.redhat.com/errata/RHSA-2023:3644

            Errata Tool added a comment - Since the problem described in this issue should be resolved in a recent advisory, it has been closed. For information on the advisory (Important: Red Hat OpenShift Service Mesh Containers for 2.4.0), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:3644

            Francisco Herrera Lira added a comment -

            The only remaining task here are Doc related and one test case that needs to be created and added to the maistra test tool (Also this test case was tested manually and the behavior is the expected)

            Francisco Herrera Lira added a comment - The only remaining task here are Doc related and one test case that needs to be created and added to the maistra test tool (Also this test case was tested manually and the behavior is the expected)

            Marko Luksa added a comment - - edited

            Implementation dilemmas that must be resolved:

            • how to configure the SMMR by default (should it include all namespaces or those with the label istio-injection: enabled)
            • how to configure Kiali (difference in how it handles the combination of '**' and selectors)
            • should SMMR member list affect istio discovery (discoverySelectors)? currently, it only affects injection; discovery is performed in all namespaces

            Marko Luksa added a comment - - edited Implementation dilemmas that must be resolved: how to configure the SMMR by default (should it include all namespaces or those with the label istio-injection: enabled ) how to configure Kiali (difference in how it handles the combination of '**' and selectors) should SMMR member list affect istio discovery (discoverySelectors)? currently, it only affects injection; discovery is performed in all namespaces

            Jamie Longmuir added a comment -

            mluksa@redhat.com 

            We've decided to remove the ServiceMeshMemberRoll in Project Sail and use namespace labels instead (just like upstream). We may end up keeping the ServiceMeshMember in order to allow regular users to add a namespace to the mesh. With this in mind, we decided that the cluster-wide option in 2.4 should not require the use of the ServiceMeshMemberRoll. So, instead of implementing namespace inclusion/exclusion via label selectors in the SMMR, we'll instead use the existing upstream mechanisms for namespace inclusion when you set the controlPlaneMode to ClusterWide. Any concerns?

            This all sounds great to me! I like the upstream alignment.

            Jamie Longmuir added a comment - mluksa@redhat.com   We've decided to remove the ServiceMeshMemberRoll in Project Sail and use namespace labels instead (just like upstream). We may end up keeping the ServiceMeshMember in order to allow regular users to add a namespace to the mesh. With this in mind, we decided that the cluster-wide option in 2.4 should not require the use of the ServiceMeshMemberRoll. So, instead of implementing namespace inclusion/exclusion via label selectors in the SMMR, we'll instead use the existing upstream mechanisms for namespace inclusion when you set the controlPlaneMode to ClusterWide. Any concerns? This all sounds great to me! I like the upstream alignment.

            Tim O'Keefe added a comment -

            tsze@redhat.com I asked a similar question during our meeting, but not the exact same one. Here is a link to the statement on the customer portal about TP feature support:

            https://access.redhat.com/support/offerings/techpreview/?extIdCarryOver=true&sc_cid=701f2000001OH74AAG

            It does state: "As a result, if you are using Technology Preview features, you may not be able to seamlessly upgrade to subsequent releases of that feature."

            So, as we learn more and make product decisions, I think we'll be ok.

            Tim O'Keefe added a comment - tsze@redhat.com I asked a similar question during our meeting, but not the exact same one. Here is a link to the statement on the customer portal about TP feature support: https://access.redhat.com/support/offerings/techpreview/?extIdCarryOver=true&sc_cid=701f2000001OH74AAG It does state: "As a result, if you are using Technology Preview features, you may not be able to seamlessly upgrade to subsequent releases of that feature." So, as we learn more and make product decisions, I think we'll be ok.

            John Mazzitelli added a comment -

            related kiali github issue that surrounds istio discovery selectors: https://github.com/kiali/kiali/issues/3914

            John Mazzitelli added a comment - related kiali github issue that surrounds istio discovery selectors: https://github.com/kiali/kiali/issues/3914

            To Hung Sze added a comment -

            Not following all the details so my apology if this is not a concern or already answered:
            is there a migration path or concern for customers who already used 2.3's version of Cluster-wide install?
            Thanks.

            To Hung Sze added a comment - Not following all the details so my apology if this is not a concern or already answered: is there a migration path or concern for customers who already used 2.3's version of Cluster-wide install? Thanks.

            John Mazzitelli added a comment - - edited

            We just have to keep in mind that as namespaces are added/removed from the mesh, we may have to update the Kiali CR (like we already do today when the SMMR changes).

            For "cluster-wide mesh" - I was under the assumption that meant ALL namespaces cluster-wide are in the mesh. If that is true, then in that case no changes need to be made to Kiali - the Kiali "accessible_namespaces" setting can keep its value of "**". But for the cases where only a subset of namespaces are in the mesh, we most likely will want to keep Kiali restricted to only seeing those namespaces. In that case, we have to maintain the Kiali CR "accessible_namespaces" value to include only those namespaces in the mesh. Today the OSSM Operator does this - whenever SMMR changes its membership, the OSSM operator also updates the Kiali CR's "accessible_namespaces" to match.

            To include/exclude namespaces, there are other features in Kiali we can utilize, see:

            https://kiali.io/docs/configuration/kialis.kiali.io/#.spec.api.namespaces.label_selector_include

            https://kiali.io/docs/configuration/kialis.kiali.io/#.spec.api.namespaces.label_selector_exclude

            https://kiali.io/docs/configuration/kialis.kiali.io/#.spec.api.namespaces.include 

            https://kiali.io/docs/configuration/kialis.kiali.io/#.spec.api.namespaces.exclude

             

             

            John Mazzitelli added a comment - - edited We just have to keep in mind that as namespaces are added/removed from the mesh, we may have to update the Kiali CR (like we already do today when the SMMR changes). For "cluster-wide mesh" - I was under the assumption that meant ALL namespaces cluster-wide are in the mesh. If that is true, then in that case no changes need to be made to Kiali - the Kiali "accessible_namespaces" setting can keep its value of "**". But for the cases where only a subset of namespaces are in the mesh, we most likely will want to keep Kiali restricted to only seeing those namespaces. In that case, we have to maintain the Kiali CR "accessible_namespaces" value to include only those namespaces in the mesh. Today the OSSM Operator does this - whenever SMMR changes its membership, the OSSM operator also updates the Kiali CR's "accessible_namespaces" to match. To include/exclude namespaces, there are other features in Kiali we can utilize, see: https://kiali.io/docs/configuration/kialis.kiali.io/#.spec.api.namespaces.label_selector_include https://kiali.io/docs/configuration/kialis.kiali.io/#.spec.api.namespaces.label_selector_exclude https://kiali.io/docs/configuration/kialis.kiali.io/#.spec.api.namespaces.include   https://kiali.io/docs/configuration/kialis.kiali.io/#.spec.api.namespaces.exclude    

            Marko Luksa added a comment -

            jlongmui@redhat.com We've decided to remove the ServiceMeshMemberRoll in Project Sail and use namespace labels instead (just like upstream). We may end up keeping the ServiceMeshMember in order to allow regular users to add a namespace to the mesh. With this in mind, we decided that the cluster-wide option in 2.4 should not require the use of the ServiceMeshMemberRoll. So, instead of implementing namespace inclusion/exclusion via label selectors in the SMMR, we'll instead use the existing upstream mechanisms for namespace inclusion when you set the controlPlaneMode to ClusterWide. Any concerns?

            Marko Luksa added a comment - jlongmui@redhat.com We've decided to remove the ServiceMeshMemberRoll in Project Sail and use namespace labels instead (just like upstream). We may end up keeping the ServiceMeshMember in order to allow regular users to add a namespace to the mesh. With this in mind, we decided that the cluster-wide option in 2.4 should not require the use of the ServiceMeshMemberRoll. So, instead of implementing namespace inclusion/exclusion via label selectors in the SMMR, we'll instead use the existing upstream mechanisms for namespace inclusion when you set the controlPlaneMode to ClusterWide. Any concerns?

              mluksa@redhat.com Marko Luksa
              jlongmui@redhat.com Jamie Longmuir
              Francisco Herrera Lira, John Mazzitelli, Prachi Yadav, Tim O'Keefe
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: