Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-8802

Enable priorityClassName configuration for ArgoCD components within the ArgoCD Custom Resource in OpenShift GitOps/ArgoCD

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • GitOps
    • None
    • None
    • Product / Portfolio Work
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      1. Proposed title of this feature request 
        Enable priorityClassName configuration for ArgoCD components within the ArgoCD Custom Resource in OpenShift GitOps/ArgoCD
      2.  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.
      3. 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.
      4.  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

              showeimer Sho Weimer
              rhn-support-arayadav Aradhana .
              None
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                None
                None