• Product / Portfolio Work
    • OCPSTRAT-2981Fleet-wide service mesh management with ACM
    • False
    • Hide

      None

      Show
      None
    • False
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Feature Overview (aka. Goal Summary)  

      An elevator pitch (value statement) that describes the Feature in a clear, concise way.  Complete during New status.

      An ACM plugin that will make it easier and more efficient to deploy and manage service mesh across a large number of clusters. While we support multi-cluster today, managing mesh resource at scale (5+ clusters) can quickly become tedious. With customers deploying mesh across hundreds of clusters, they need additional support for common configuration management tasks.

      RH ACM offers the ability to create plugins (https://open-cluster-management.io/docs/concepts/add-on-extensibility/addon/) to extend its functionality. This provides an opportunity for OpenShift Service Mesh to better leverage ACM for deploying and managing service meshes across multiple clusters.

      Goals (aka. expected user outcomes)

      The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. Complete during New status.

      Such a plugin would help to address configuration challenges when deploying and managing service mesh across a large number of clusters. This includes (but not limited to):

      • Setting up Istio's multi-cluster topologies such as multi-primary, primary-remote and external control planes given a set of clusters.
      • Configuring Istio integrations globally - such as metrics, tracing, cert-manager, spire, etc. so that you don't have to repeat the same config.
      • Converging configuration for services that may exist in multiple mesh deployments. For example, an AuthorizationPolicy or VS/DR resource set that is intended to be deployed across multiple service mesh instances.

       

      Requirements (aka. Acceptance Criteria):

      A list of specific needs or objectives that a feature must deliver in order to be considered complete.  Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.  Initial completion during Refinement status.

      This feature should reuse as many functions of the sail-operator as possible. If a feature would better supported via the sail-operator, favour implementing it there over the ACM addon. It is important that the ACM addon be kept thin and maintainable across Istio releases.

      From a workflow perspective, the feature should support GitOps style workflows, and may work with Argo (OpenShift GitOps) where needed.

      Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

      Deployment considerations List applicable specific needs (N/A = not applicable)
      Self-managed, managed, or both Y
      Classic (standalone cluster) Y
      Hosted control planes Y
      Multi node, Compact (three node), or Single node (SNO), or all Multi - ACM
      Connected / Restricted Network Y
      Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x) All
      Operator compatibility N
      Backport needed (list applicable versions) 3.4 earliest release
      UI need (e.g. OpenShift Console, dynamic plugin, OCM) Y - there is a separate feature for an ACM dashboard to support
      Other (please specify)  

      Use Cases (Optional):

      Engineering is outlining an initial MVP here.

      Initial use cases (for an MVP) will focus on the configuration and management of a multi-primary multi-network topology across many clusters.

      Questions to Answer (Optional):

      Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

      <your text here>

      Out of Scope

      High-level list of items that are out of scope.  Initial completion during Refinement status.

      <your text here>

      Background

      Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

      <your text here>

      Customer Considerations

      Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

      <your text here>

      Documentation Considerations

      Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

      <your text here>

      Interoperability Considerations

      Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

      <your text here>

              Unassigned Unassigned
              jlongmui@redhat.com Jamie Longmuir
              None
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: