Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-8776

Improve performance and reduce footprint of OpenShift GitOps

XMLWordPrintable

    • False
    • Hide

      None

      Show
      None
    • False
    • GITOPS-8774Single-cluster scalability of GitOps

      < High-Level description of the feature ie: Executive Summary >

      Goals

      Vertical scalability of Argo CD's application controller is severely limited by the way the cluster cache(s) are being built up. A lot of CPU, memory and network connections are consumed depending on various factors of the managed cluster(s). The caching needs to be improved to consume less resources, preferably by using an approach such as lazy cache setup, i.e. only establish watches and caches for resources that are actually used by the applications managed through Argo CD.

      Requirements

      Requirements Notes IS MVP
      Cluster cache is optimized to only cache resources/APIs in use and not the whole cluster    
      Established watches to the K8s API are reduced to the minimum Argo CD requires to managed configured applications    
      The cache and watches are established and tore down dynamically with regards to managed resources     

      (Optional) Use Cases

      • As a user of OpenShift GitOps in cluster scoped mode, I want to manage multiple clusters with my Argo CD instance without worrying too much about resource consumption
      • As a user of OpenShift GitOps in namespace scoped mode, I want to be able to manage more than a couple of namespaces without running into performance issues

      Out of scope

      <Defines what is not included in this story>

      Dependencies

      < Link or at least explain any known dependencies. >

      Background, and strategic fit

      < What does the person writing code, testing, documenting need to know? >

      Assumptions

      < Are there assumptions being made regarding prerequisites and dependencies?>

      < Are there assumptions about hardware, software or people resources?>

      Customer Considerations

      < Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

      Documentation Considerations

      < What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

      What does success look like?

      < Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>

      QE Contact

      < Are there assumptions being made regarding prerequisites and dependencies?>

      < Are there assumptions about hardware, software or people resources?>

      Impact

      < If the feature is ordered with other work, state the impact of this feature on the other work>

      Related Architecture/Technical Documents

      <links>

      Done Checklist

      • Acceptance criteria are met
      • Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
      • User Journey automation is delivered
      • Support and SRE teams are provided with enough skills to support the feature in production environment

              rh-ee-anjoseph Anand Francis Joseph
              jfischer@redhat.com Jann Fischer
              Votes:
              1 Vote for this issue
              Watchers:
              12 Start watching this issue

                Created:
                Updated: