-
Feature
-
Resolution: Unresolved
-
Critical
-
None
-
None
-
None
-
False
-
-
False
-
-
-
< 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
- impacts account
-
GITOPS-4689 OpenShift GitOps performance improvement
-
- New
-
- is duplicated by
-
GITOPS-4134 Investigate OpenShift GitOps Perfomance Improvements
-
- Closed
-
- relates to
-
GITOPS-2657 openshift gitops having issues when it controls too many namespace
-
- Closed
-
-
ACM-19505 ACM Performance Tuning Guide for Gitops
-
- New
-