ArgoCD Resources Should Be Configurable via values.yaml

[paladugu-anand]

ArgoCD Resources Should Be Configurable via values.yaml

Summary

The ClusterGroup Helm chart hardcodes ArgoCD component resource requests and limits in templates/plumbing/argocd.yaml, making it impossible for users to configure these values
through standard Helm values override mechanisms. This creates significant operational challenges for production deployments that require different resource allocations.

---

Current Behavior

File: templates/plumbing/argocd.yaml (lines 29-96, 178-184)

The following ArgoCD components have hardcoded resource values:

1. ArgoCD Server

server:
  resources:
    limits:
      cpu: 500m
      memory: 256Mi
    requests:
      cpu: 125m
      memory: 128Mi

2. Application Controller

controller:
  resources:
    limits:
      cpu: "4"
      memory: 4Gi
    requests:
      cpu: 500m
      memory: 2Gi

3. ApplicationSet Controller

applicationSet:
  resources:
    limits:
      cpu: "2"
      memory: 1Gi
    requests:
      cpu: 250m
      memory: 512Mi

4. Repo Server

repo:
  resources:
    limits:
      cpu: "1"
      memory: 1Gi
    requests:
      cpu: 250m
      memory: 256Mi

5. Dex (SSO)

dex:
  resources:
    limits:
      cpu: 500m
      memory: 256Mi
    requests:
      cpu: 250m
      memory: 128Mi

Problem: These values are NOT exposed in values.yaml, so users standard Helm mechanisms.

---

Impact on Users

1. Production Deployments Require Higher Resources

Many production environments need significantly higher resource allocatio

• Large Application Counts: Clusters managing 100+ ArgoCD Application (8Gi+ instead of 4Gi)
• Complex Manifests: Large Helm charts or Kustomize overlays require more repo-server CPU/memory
• High Sync Frequency: Frequent synchronization operations require hi
• Multi-Cluster Management: Hub clusters managing multiple edge clusters need increased controller resources

2. Complex and Fragile Workarounds Required

Without values.yaml configuration, users must implement brittle workarounds:

Workaround A: Post-Deployment Patching

# After chart deployment, manually patch ArgoCD resources
oc patch argocd <name> -n <namespace> --type merge -p '{
  "spec": {
    "server": {
      "resources": {
        "limits": {"cpu": "1", "memory": "512Mi"},
        "requests": {"cpu": "250m", "memory": "256Mi"}
      }
    }
  }
}'

Problems:

• ❌ Manual intervention required on every cluster
• ❌ Not declarative or GitOps-friendly
• ❌ Patches are overwritten on chart upgrades
• ❌ Requires documentation and runbooks

Workaround B: Configure ArgoCD to Ignore Differences

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: clustergroup-app
spec:
  ignoreDifferences:
  - group: argoproj.io
    kind: ArgoCD
    jsonPointers:
    - /spec/server/resources
    - /spec/controller/resources
    - /spec/applicationSet/resources
    - /spec/repo/resources
    - /spec/dex/resources

Problems:

• ❌ ArgoCD will show perpetual "OutOfSync" status
• ❌ Ignores ALL resource changes, not just user overrides
• ❌ Masks legitimate drift from desired state
• ❌ Reduces confidence in GitOps automation
• ❌ Complicates troubleshooting

Workaround C: Fork and Maintain Custom Chart

# Fork clustergroup-chart repository
# Modify hardcoded values
# Maintain fork and merge upstream changes

Problems:

• ❌ Significant maintenance burden
• ❌ Delays receiving upstream bug fixes and features
• ❌ Increases divergence from community-supported chart
• ❌ Requires Helm packaging and hosting infrastructure

---

Expected Behavior

ArgoCD component resources should be configurable via values.yaml w

Proposed values.yaml Structure

clusterGroup:
  argoCD:
    # ... existing configuration ...

    # ArgoCD component resource configuration
    resources:
      server:
        limits:
          cpu: 500m
          memory: 256Mi
        requests:
          cpu: 125m
          memory: 128Mi

      controller:
        limits:
          cpu: "4"
          memory: 4Gi
        requests:
          cpu: 500m
          memory: 2Gi

      applicationSet:
        limits:
          cpu: "2"
          memory: 1Gi
        requests:
          cpu: 250m
          memory: 512Mi

      repo:
        limits:
          cpu: "1"
          memory: 1Gi
        requests:
          cpu: 250m
          memory: 256Mi

      dex:
        limits:
          cpu: 500m
          memory: 256Mi
        requests:
          cpu: 250m
          memory: 128Mi

Proposed Template Changes

File: templates/plumbing/argocd.yaml

Current (Hardcoded):

server:
  resources:
    limits:
      cpu: 500m
      memory: 256Mi
    requests:
      cpu: 125m
      memory: 128Mi

Proposed (Configurable with Defaults):

server:
  resources:
{{- if $.Values.clusterGroup.argoCD.resources.server }}
{{ toYaml $.Values.clusterGroup.argoCD.resources.server | indent 4 }}
{{- else }}
    limits:
      cpu: 500m
      memory: 256Mi
    requests:
      cpu: 125m
      memory: 128Mi
{{- end }}

*(Apply similar pattern to controller, applicationSet, repo, and dex sect

---

Benefits of This Change

1. Standard Helm Best Practices

✅ Follows Helm chart conventions for configurability
✅ Allows per-environment customization through values files
✅ Enables GitOps-friendly declarative configuration

2. Improved User Experience

✅ No manual post-deployment intervention required
✅ No need to configure ArgoCD ignoreDifferences
✅ No requirement to fork and maintain custom charts
✅ Clean ArgoCD sync status without perpetual drift

3. Production-Ready Flexibility

✅ Small dev/test clusters can use default (smaller) values
✅ Production clusters can easily scale resources via values.yaml
✅ Different resource profiles per cluster in multi-cluster deployments

4. Backward Compatibility

✅ Existing deployments continue working with default values
✅ No breaking changes to chart interface
✅ Optional configuration - defaults provided if not specified

---

Use Cases

Use Case 1: Large-Scale Hub Cluster

Scenario: Hub cluster managing 50+ edge clusters with 200+ ArgoCD App

Current: Forced to use workarounds, manual patches, or custom chart f
With Fix: Simple values.yaml override:

clusterGroup:
  argoCD:
    resources:
      controller:
        limits:
          cpu: "8"
          memory: 16Gi
        requests:
          cpu: "2"
          memory: 8Gi

---

Use Case 2: Resource-Constrained Edge Cluster

Scenario: Edge cluster on minimal hardware needs lower resource alloc

Current: Default values may be too high, causing scheduling issues
With Fix: Reduce resource requests via values.yaml:

clusterGroup:
  argoCD:
    resources:
      controller:
        requests:
          cpu: 250m
          memory: 1Gi

---

Use Case 3: Multi-Environment Pattern Deployment

Scenario: Same pattern deployed across dev/staging/prod with different resource needs

Current: All environments forced to use same hardcoded resources
With Fix: Environment-specific values files:

values-dev.yaml:

clusterGroup:
  argoCD:
    resources:
      controller:
        limits: {cpu: "2", memory: 2Gi}

values-prod.yaml:

clusterGroup:
  argoCD:
    resources:
      controller:
        limits: {cpu: "8", memory: 16Gi}

---

Proposed Implementation

Step 1: Update values.yaml

Add clusterGroup.argoCD.resources section with defaults matching current hardcoded values (for backward compatibility)

Step 2: Update templates/plumbing/argocd.yaml

Replace hardcoded resource blocks with templated values using toYaml he

Step 3: Update values.schema.json

Add JSON schema validation for new resource configuration section

Step 4: Update Documentation

• Add resource configuration examples to README.md
• Document resource sizing recommendations for different deployment scales
• Add migration guide for users currently using workarounds

---

Additional Context

Related Patterns

Other Validated Patterns charts (like gitops-operator, acm-chart) already follow similar patterns for resource configuration, making this change consistent with the broader V
alidated Patterns ecosystem.

ArgoCD CR Specification

The ArgoCD Operator's CRD already supports these resource configurations - this change simply exposes that existing capability through Helm values.

Community Feedback

Multiple users have encountered this limitation in production deploymentsnds described above, indicating this is a real pain point.

---

Acceptance Criteria

• All ArgoCD component resources (server, controller, applicationSet,via values.yaml
• Default values match current hardcoded values (backward compatibility)
• Values schema validation added for resource configuration
• Documentation updated with configuration examples
• Resource sizing guidance provided for different deployment scales
• Existing chart deployments continue working without changes
• New deployments can override resources through standard Helm values

---

References

• ClusterGroup Chart Repository: https://github.com/validatedpatterns/clustergroup-chart
• ArgoCD Operator CRD: https://argocd-operator.readthedocs.io/en/latest/reference/argocd/
• Helm Best Practices - Values: https://helm.sh/docs/chart_best_practices/values/

---

Priority

High - This limitation affects production deployments and forces userrounds that violate GitOps principles.