We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The helm chart's values.controlPlane.backingStore.etcd.deploy.statefulSet.persistence.volumeClaim.storageClass is ignored and the default storageClass is used. This seems to be due to https://github.com/loft-sh/vcluster/blob/v0.20.0-beta.2/chart/templates/etcd-statefulset.yaml#L47 referencing className rather than storageClass.
values.controlPlane.backingStore.etcd.deploy.statefulSet.persistence.volumeClaim.storageClass
className
storageClass
Specifying a storageClass for etcd would work
Deploy with Helm using the following values.yaml:
controlPlane: backingStore: etcd: deploy: enabled: true statefulSet: persistence: volumeClaim: className: rook-cephfs
No response
$ kubectl version Client Version: v1.29.3 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 Server Version: v1.28.4+k3s2
k3s
k8s I think; I did not specify and this is on v0.20
OS: Rocky Linux 9 Arch: x86_64
The text was updated successfully, but these errors were encountered:
We also have the same issue... in EKS with k3s and etcd it always uses gp2
Sorry, something went wrong.
Hi @virtualdxs 👋 , Thanks for creating this issue and @joaocc also for confirming.
I am looking into this issue and fix is on the way.
neogopher
Successfully merging a pull request may close this issue.
What happened?
The helm chart's
values.controlPlane.backingStore.etcd.deploy.statefulSet.persistence.volumeClaim.storageClass
is ignored and the default storageClass is used. This seems to be due to https://github.com/loft-sh/vcluster/blob/v0.20.0-beta.2/chart/templates/etcd-statefulset.yaml#L47 referencingclassName
rather thanstorageClass
.What did you expect to happen?
Specifying a storageClass for etcd would work
How can we reproduce it (as minimally and precisely as possible)?
Deploy with Helm using the following values.yaml:
Anything else we need to know?
No response
Host cluster Kubernetes version
Host cluster Kubernetes distribution
vlcuster version
Vcluster Kubernetes distribution(k3s(default)), k8s, k0s)
k8s I think; I did not specify and this is on v0.20
OS and Arch
The text was updated successfully, but these errors were encountered: