Epic Goal

Goals:

• Provide an option in ArgoCD CR to specify the storage capacity, type and reclaim policy, so that customers can make use of these configurations when working with larger git repositories.

Non-goals:

Maps-to:

Value:

Why is this important?

Background information

upstream issue

Currently ArgoCD Repo server uses EmptyDir as the storage volume type with no fixed capacity specified. This will use Nodes ephemeral storage and is limited. For Customers who have larger manifests and operating with too many repositories, this storage space may not be sufficient. By providing an option to customers for providing a larger storage capacity, customers can work with larger repos and manifests.

In the ArgoCD scaling up documentation, it has been mentioned to use a persistent volume for scaling up for a larger disk space.

https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/#scaling-up

argocd-repo-server clones the repository into /tmp (or the path specified in the TMPDIR env variable). The Pod might run out of disk space if it has too many repositories or if the repositories have a lot of files. To avoid this problem mount a persistent volume.

Impact if not implemented

If not implemented, there would be a need to limit the size of git repositories that can be used by customers for creating applications. If larger repos are used, the repo-server pod will run out of disk space and might crash.

Additional information

The ArgoCD CRD, could have new fields added for storage. If not configured, the default storage can be EmptyDir. Customers can update the storage section to have the required capacity and storage class.

spec: 
   repo: 
     resources: 
       limits: 
         memory: 4G
         cpu: 2
       requests: 
         memory: 2G
         cpu: 1
     storage: 
       capacity: 20G
       storageClass: aws-efs
       reclaimPolicy: delete

When custom storage fields are specified, the operator should create a PVC (instead of an EmptyDir) and use that for the storage. The PVC should be entirely managed by the operator. The reclaim policy of the PVC can be set to delete by default.

Implemented Approach

User is responsible to create and manage the required Persistent Volume (PV) and Persistent Volume Claim (PVC) resources according to their storage needs and environment and can mount it via ArgoCD CR using following configuration. 

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd-sample
spec:
  repo:
    volumes:
    - name: repo-storage
      persistentVolumeClaim:
        claimName: <persistent-volume-claim>
    volumeMounts:
    - mountPath: /tmp
      name: repo-storage 

Acceptance Criteria (Mandatory)

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. ...

Open questions::

1. ...

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment