Loki: Persistent Volume storageClassName not sticking

[christopher-wong]

Describe the bug
When setting the storageClassName for Loki, it still uses "default"

To Reproduce

$ kubectl get storageclass

NAME            PROVISIONER             AGE
gp2             kubernetes.io/aws-ebs   20d
io1 (default)   kubernetes.io/aws-ebs   3h42m

$ helm upgrade --install loki loki/loki --set "loki.persistence.enabled=true,loki.persistence.storageClassName=io1"

$ kubectl get events -n monitoring
57s         Warning   ProvisioningFailed       PersistentVolumeClaim   storageclass.storage.k8s.io "default" not found

$ kubectl get pv,pvc,pod -n monitoring
NAME                                            STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/grafana                   Bound     pvc-xxx   128Gi      RWO            io1            18m
persistentvolumeclaim/storage-loki-0            Pending                                                                        default        26h

Expected behavior
I expect Loki to create an io1 volume and not get stuck "pending" create of a "default" storageClass

Environment:

• Infrastructure: Kubernetes, EKS
• Deployment tool: helm

[steven-sheehy]

If you're installing the loki chart directly and not embedding it as a sub-chart, you shouldn't prefix variables with loki. So it should be:

$ helm upgrade --install loki loki/loki --set "persistence.enabled=true,persistence.storageClassName=io1"

[Bogdan-Catalin]

I have the same issue, but am using loki-stack
helm upgrade --install loki loki/loki-stack --set loki.persistence.enabled=true --set loki.persistence.size=100 --set loki.persistence.storageClassName=standard

What I find confusing is that in the statefulset volume claim template has storage class name of "standard", but a pvc resource of "default" storage class is created. Is this expected ?

Edit: ok, I realized that the PVC isn't deleted after delete --purge ing the deployment. On my first try I didn't specifcy a storage class name, so the "default" name was used instead, which doesn't exist in my cluster. Solution was to delete it and above command works like a charm.