Proposed title of this feature request
Enable priorityClassName configuration for ArgoCD components within the ArgoCD Custom Resource in OpenShift GitOps/ArgoCD
What is the nature and description of the request?
Request to expose the priorityClassName field in the ArgoCD Custom Resource (CRD) for all core components managed by the OpenShift GitOps Operator (including the Application Controller, Repo Server, API Server, and Redis).
Currently, the Operator does not provide a mechanism to specify a PriorityClass in the Pod spec of these components. This forces ArgoCD pods to run with the global default priority (typically 0). This enhancement would bring the operator's CRD in line with the ArgoCD Helm chart, which already supports this functionality.
Why does the customer need this? (List the business requirements here)
Infrastructure Stability during Resource Contention: In our cluster we use PriorityClasses to allow users to assign different priorities to their workloads. High-priority user workloads (priority value: 2000) often scale dynamically.
Prevention of Management-Plane "Blindness": Without high priority, the ArgoCD Application Controller is a candidate for eviction during node memory or CPU pressure caused by user workloads. If ArgoCD is evicted, administrators lose the ability to manage, scale down, or roll back the very workloads causing the resource pressure.
Predictable Scheduling: Management infrastructure must be "untouchable" by user-tier workloads to ensure the GitOps state is maintained even when the cluster is at 100% capacity.
Compliance with Best Practices: Kubernetes best practices dictate that system-critical management tools should run with a higher priority than the workloads they manage.
List any affected packages or components.
Red Hat OpenShift GitOps Operator
CRD: argoproj.io/v1beta1/argocd
affected components (Pods/Deployments):
argocd-application-controller (StatefulSet)
argocd-applicationset-controller
argocd-dex-server
argocd-redis
argocd-repo-server
argocd-server