dex-server and notifications controller hard coded replicas

[kirrmann]

Describe the bug

Both the deployments have a hard coded replicas: 1, which is surprising because for both a PDB can be setup. Is there any reason for setting this fixed values and not exposing it in values.yaml?

Related helm chart

argo-cd

Helm chart version

7.7.1

To Reproduce

See dex deployment template and notifications-controller deployment-template to see that replicas is hard coded to 1

Expected behavior

notifications.replicas and dex.replicas should be exposed as a setting in values.yaml

Screenshots

No response

Additional context

No response

[kirrmann]

If this is not intended then I can create a Pull Request

[mkilchhofer]

Re: Dex

Dex is intended and also the background is documented:

The argocd-dex-server uses an in-memory database, and two or more instances would have inconsistent data.

Source: https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/#argocd-dex-server-argocd-redis

Re: Notification controller

There are various issues upstream when running more than one replica, e.g.:

• Duplicated notifications based on argocd-notifications-controller replica count argo-cd#17338

[kirrmann]

Looking at dex I assume if we would use external storage then we could run dex in ha https://dexidp.io/docs/configuration/storage/ I also found this question about it dexidp/dex#2256

[mkilchhofer]

Yes Dex (deployed as a Standalone instance) can run in HA mode.

But Dex embedded in Argo CD does not support HA. If you think it is worth implementing HA also for the embedded Dex, it would be nice if you can file an issue in the upstream repository: https://github.com/argoproj/argo-cd/issues/new/choose

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.