feat(argo-cd): Add Volume Pesistence support for argocd-repo-server

[arielly-parussulo]

• allow argocd-repo-server to be deployed as a StatefulSet.
• allow the creation of Persistent Volumes for argocd-repo-server.

Checklist:

• I have bumped the chart version according to versioning
• I have updated the documentation according to documentation
• I have updated the chart changelog with all the changes that come with this pull request according to changelog.
• Any new values are backwards compatible and/or have sensible default.
• I have signed off all my commits as required by DCO.
• My build is green (troubleshooting builds).

Changes are automatically published when merged to main. They are not published on branches.

[pdrastil]

I'm little bit worried about this implementation because repo server is stateless, not stateful and typically runs with HPA (we run 30+ replicas). This feature will break the HPA that targets Deployment + will create large amount of PVCs.

[bschaeffer]

Just... don't enable statefulset mode?

[pdrastil]

Hi @arielly-parussulo thanks for contribution.

I personally believe that persistence should be more complex feature. For reason mentioned above the repo server would ideally use 1 shared PVC with ReadWriteMultiple mode so all repositories can share already downloaded resources instead of trying to create lots of PVCs that will eventually converge to the same content. I believe 1 disk per replica would work ok with NFS backend and only a few replicas.

I can imagine that this should have at least following:

1. global.persistence with defaults for new PVCs
2. component level overrides (mapping to volumes)
3. option to choose between PVC (created, existing), in-memory emptyDir and ephemeral emptyDir
4. must be compatible with current HPAs

I think this might be good base but feature should be extended.

[arielly-parussulo]

Hi @arielly-parussulo thanks for contribution.

I personally believe that persistence should be more complex feature. For reason mentioned above the repo server would ideally use 1 shared PVC with ReadWriteMultiple mode so all repositories can share already downloaded resources instead of trying to create lots of PVCs that will eventually converge to the same content. I believe 1 disk per replica would work ok with NFS backend and only a few replicas.

I can imagine that this should have at least following:

1. global.persistence with defaults for new PVCs
2. component level overrides (mapping to volumes)
3. option to choose between PVC (created, existing), in-memory emptyDir and ephemeral emptyDir
4. must be compatible with current HPAs

I think this might be good base but feature should be extended.

Cool! I think I can add some of these features in this PR. I've added the StatefulSet feature because I saw some people mentioning that in this issue and we ended up using it in my company as we have less replicas and a monorepo that ends up causing a DiskPressure issue in our pods. So I still think that it could be an option in the Helm Chart.
But I agree with you about the other features. I will try to improve this PR to add more persistency features for argocd-repo-server.

[pdrastil]

Please also go though this thread argoproj/argo-cd#7927 as this chart mirrors what's in the upstream.

[Gianluca755]

Sorry for asking @pdrastil, is it possible to have feature even if it's still in beta? @arielly-parussulo haven't pushed in 3 weeks. I can contribute if needed. Thanks

[github-actions]

This pull request 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.

[pierluigilenoci]

Any news about this?

[zswanson]

For reason mentioned above the repo server would ideally use 1 shared PVC with ReadWriteMultiple mode

Just to note, ReadWriteMany isn't well supported by cloud vendors when pods are on different nodes. Neither GKE nor EKS allow ReadWriteMany when you're using PD or EBS as the volume type.

[pierluigilenoci]

@pdrastil using ReadWriteMany necessarily imposes the use of some NFS (for example, EFS from AWS) with a significant reduction in performance (for example, in Azure, SMB is used, which has embarrassing performance) as well as essential limitations in cases of clusters that operate multi-AZ.
One day, it will be a concrete option, but today it is only a good theoretical idea that collides with the limits of the various cloud providers.

[clement94310]

hello
we also need a pvc on our repo server does someone know if this PR will be merge soon ?

[bschaeffer]

Whats the deal with this feature? We currently run a large monorepo and we have to use kustomize to change the repo-server to a statefulset with PVCs. Would be nice if this was supported out of the box.

[vitas]

Please, proceed with the PR , this feature is very important for HA and would be aligned with redis-ha charts

[yann-soubeyrand]

Sorry for the noise, I did not find a way to remove myself from requested reviewers other than by doing a review 😟

[Daverkex]

Hi @arielly-parussulo thanks for contribution.

I personally believe that persistence should be more complex feature. For reason mentioned above the repo server would ideally use 1 shared PVC with ReadWriteMultiple mode so all repositories can share already downloaded resources instead of trying to create lots of PVCs that will eventually converge to the same content. I believe 1 disk per replica would work ok with NFS backend and only a few replicas.

I can imagine that this should have at least following:

1. global.persistence with defaults for new PVCs

2. component level overrides (mapping to volumes)

3. option to choose between PVC (created, existing), in-memory emptyDir and ephemeral emptyDir

4. must be compatible with current HPAs

I think this might be good base but feature should be extended.

That is a very interesting point. But in my honest opinion, we are overengineering here. I mean, currently this is the current behavior. In a deploy, every pod copies “randomly” the repo needed. This feature is an improvement to mitigate the copy per pod. Every time the pod is migrated to another node, the process starts again. With a PVC, this part is solved.
My only concern is how the repo server deletes old or unused clones to avoid an infinite disk in an infinite time.
Step 2 could be the improvement you suggest: a shared system for all the pods to not only mitigate the copy per pod but also limit the total copy combined. Several options here: an S3 backend, a ReadWriteMany...

This PR could be step one, then a more sophisticated approach for step two.