fix: Remove dependency on argocd-redis secret

[jparsai]

This PR is to remove dependency of argocd-redis secret in NewClusterCacheInstance function, because of this users of GitOps operator are forced to create argocd-redis secret manually as operator uses argocd-redis-initial-password instead. Now we have a new env variable in principal to provide redis password and principal would use this to get redis password instead of looking for argocd-redis secret

[codecov-commenter]

Codecov Report

❌ Patch coverage is 61.11111% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 45.61%. Comparing base (427206b) to head (d0600c7).

Files with missing lines	Patch %	Lines
cmd/argocd-agent/principal.go	0.00%	5 Missing ⚠️
principal/options.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #587      +/-   ##
==========================================
- Coverage   45.63%   45.61%   -0.03%     
==========================================
  Files          90       90              
  Lines       12020    12019       -1     
==========================================
- Hits         5485     5482       -3     
- Misses       6090     6093       +3     
+ Partials      445      444       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jgwest]

Since we will be deploying principal via ArgoCD resource in GitOps operator and it does not create argocd-redis secret and makes use of argocd-redis-initial-password and because of this users are forced to create argocd-redis secret and copy password from argocd-redis-initial-password. To avoid this inconvenience we could use argocd-redis-initial-password secret itself.

Not all users of Argo CD agent are installing principal via GitOps operator. GitOps operator is a vendor-specific (Red Hat) operator. Many users would be installing Argo CD via helm or install.yaml manifests.

The (name)-redis-initial-password Secret format (with key admin.password) is an argocd-operator invention which is not followed by other install methods.

For example, upstream argocd install.yaml uses an initContainer on the redis container to create a Secret named argocd-redis with key auth.. I presume Helm is similar.

To me, in this repo PR we should:

• Principal should have a new REDIS_PASSWORD env/param (✅ already included in this PR)
• Principal should read that value in cmd/argocd-agent/principal.go and pass that password throughout the codebase wherever it is needed (✅ included in this PR)
• In the Principal Deployment, we should ensure that REDIS_PASSWORD is mapped to the correct Secret name/field.
  • In this repo, that would be argocd-redis with field auth
• We should not change the Secret name/field from default argocd-redis to (name)-redis-initial-password, nor change the field name from auth to admin.password

Then, in argocd-operator repo: when we create the argocd-agent principal Deployment, we ensure that we map the REDIS-PASSWORD to the argocd-operator specific redis Secret format. This would be an example Deployment YAML created by argocd-operator:

kind: Deployment
#(...)
metadata:
  name: (principal Argo CD agent name)
spec:
  template:
    spec:
      containers:
      - args:
        - # (...)
        env:
        - name: REDIS_PASSWORD
          valueFrom:
            secretKeyRef:
              key: admin.password
              name: (name of CR)-initial-password  # (replace this with whatever the redis Secret name will be)
          # (non-optional env)
      # (...)

WDYT? Is there a scenario this doesn't cover?

In both cases, Argo CD agent will fail to start until the redis Secret is created, but that's fine because Kubernetes will keep trying until it exists.

[jparsai]

Since we will be deploying principal via ArgoCD resource in GitOps operator and it does not create argocd-redis secret and makes use of argocd-redis-initial-password and because of this users are forced to create argocd-redis secret and copy password from argocd-redis-initial-password. To avoid this inconvenience we could use argocd-redis-initial-password secret itself.

Not all users of Argo CD agent are installing principal via GitOps operator. GitOps operator is a vendor-specific (Red Hat) operator. Many users would be installing Argo CD via helm or install.yaml manifests.

The (name)-redis-initial-password Secret format (with key admin.password) is an argocd-operator invention which is not followed by other install methods.

For example, upstream argocd install.yaml uses an initContainer on the redis container to create a Secret named argocd-redis with key auth.. I presume Helm is similar.

To me, in this repo PR we should:

• Principal should have a new REDIS_PASSWORD env/param (✅ already included in this PR)

• Principal should read that value in cmd/argocd-agent/principal.go and pass that password throughout the codebase wherever it is needed (✅ included in this PR)

• In the Principal Deployment, we should ensure that REDIS_PASSWORD is mapped to the correct Secret name/field.

  • In this repo, that would be argocd-redis with field auth

• We should not change the Secret name/field from default argocd-redis to (name)-redis-initial-password, nor change the field name from auth to admin.password

Then, in argocd-operator repo: when we create the argocd-agent principal Deployment, we ensure that we map the REDIS-PASSWORD to the argocd-operator specific redis Secret format. This would be an example Deployment YAML created by argocd-operator:

kind: Deployment
#(...)
metadata:
  name: (principal Argo CD agent name)
spec:
  template:
    spec:
      containers:
      - args:
        - # (...)
        env:
        - name: REDIS_PASSWORD
          valueFrom:
            secretKeyRef:
              key: admin.password
              name: (name of CR)-initial-password  # (replace this with whatever the redis Secret name will be)
          # (non-optional env)
      # (...)

WDYT? Is there a scenario this doesn't cover?

In both cases, Argo CD agent will fail to start until the redis Secret is created, but that's fine because Kubernetes will keep trying until it exists.

Yes I missed that use case, my approach was to ensure that there is no other function in agent or upstream function that it calls has hard dependency on argocd-redis secret just like SetOptionalRedisPasswordFromKubeConfig function that I fixed here. So I removed argocd-redis secret to check code still works without it. I reverted my changes PTAL now.

[jgwest]

LGTM, thanks @jparsai!