[Question] Why not set fstype in default storage class

[JohnnyHuang2015]

Describe scenario
Currently we deployed the consul on azure stack with k8s version 1.22.7. However, we ran into a problem, saying permission denied when consul trying to write data to PVC. We checked out some materials and found out the our issue is quite similar with this one.

See below: https://learn.microsoft.com/en-us/azure-stack/aks-hci/known-issues-storage
Configuring persistent volume claims results in the error: 'Unable to initialize agent. Error: mkdir /var/log/agent: permission denied'.
This permission denied error indicates that the default storage class may not be suitable for your workloads and occurs in Linux workloads running on top of Kubernetes version 1.19.x or later. Following security best practices, many Linux workloads specify the securityContext fsGroup setting for a pod. The workloads fail to start on AKS on Azure Stack HCI since the default storage class does not specify the fstype (=ext4) parameter, so Kubernetes fails to change the ownership of files and persistent volumes based on the fsGroup requested by the workload.

To resolve this issue, define a custom storage class that you can use to provision PVCs.

We follow the guide and create a custom storage class. The issue was indeed resolved with this workaround.

Question
My question is why not set the fstype parameter in default storage class, is there any risk or concern? Any comments are welcome. Thanks.

[andyzhangx]

hi @JohnnyHuang2015 this is the issue on Azure Stack HCI, do you think AKS also have such issue?

[andyzhangx]

could be related to kubernetes-sigs/azuredisk-csi-driver#901 (comment), there is no such issue on AKS now, and also set fsType: ext4 in default sc is not good since default sc should also work on Windows node.