[IMPROVEMENT] feat(helm): add support for default storage class in PVCs

[dme86]

Description

I updated the Helm chart to allow the use of a default storage class when none is explicitly specified. This change is important because some Kubernetes environments, like k3d, do not have a 'standard' storage class by default.
Without this change, the setup could fail in such environments, as Kubernetes would attempt to use an undefined or missing storage class. By not explicitly setting a storage class, I allow Kubernetes to default to whatever storage class is configured for the cluster.

This ensures the chart works across various setups, including those that don't predefine a 'standard' storage class.

Type of change

• Improvement (change adding some improvement to an existing functionality)

How Has This Been Tested

Tested on a MacBook Pro M3 Max with k3d (v5.7.4) and Minikube (v1.34.0).

Checklist:

I added relevant documentation
I followed the style guidelines of this project
I did a self-review of my code
I made corresponding changes to the documentation
I confirm My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
I have added relevant notes to the CHANGELOG.md file (See https://keepachangelog.com/)

[frascuchon]

Thanks @dme86 for your contribution!

Sorry, I'm not a Kubernetes expert but would like to understand the change :-). This change will use the default configured storage class instead of the "standard" storage class which could not exist for some clusters, but users still can define a specific storage class, right?

[dme86]

@frascuchon,

You're absolutely correct in your understanding. This change updates the Helm chart to use the cluster's default storage class instead of explicitly specifying the "standard" storage class, which does not exist on all Kubernetes clusters. By doing so, we enhance the chart's compatibility across different environments.

Users still have the flexibility to define a specific storage class if needed. They can do this by setting the argilla.persistence.storageClass value in the values.yaml file or by using the --set flag during installation. For example:

helm install my-release . --set argilla.persistence.storageClass=custom-storage-class

I've noticed that the current Helm chart fails on clusters like k3d and k3s, where the default storage class is "local-path" rather than "standard". This mismatch causes deployment failures because the specified "standard" storage class doesn't exist in these environments. By defaulting to the cluster's default storage class, we ensure smoother deployments across a wider range of Kubernetes distributions.

Given that many users utilize k3d, k3s, or other lightweight Kubernetes solutions, I recommend testing the Helm chart beyond just minikube. This approach will help you make deployments as seamless and user-friendly as possible for a broader audience.

[frascuchon]

Thanks for the clarification, @dme86!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.26%. Comparing base (5622e96) to head (4118e92).
Report is 6 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #5628      +/-   ##
===========================================
- Coverage    91.28%   91.26%   -0.02%     
===========================================
  Files          145      145              
  Lines         6036     6036              
===========================================
- Hits          5510     5509       -1     
- Misses         526      527       +1     

Flag	Coverage Δ
argilla-server	91.26% <ø> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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