Unsolved
1 Rookie
•
15 Posts
0
1860
June 10th, 2021 12:00
csi-powerscale fsGroup behavior changed from 1.3.0 to 1.4.0+
It seems that between csi-powerscale v1.3.0.1 and v1.4.0, fsGroup behavior changed in the CSI.
Typically having fsGroup set in a pod spec will cause a recursive chgrp to happen each time the volume is mounted (assuming "rootClientEnabled" is true in the StorageClass, which it is in my case).
In v1.3.0.1 this happened as expected, the group ownership of the volume directory and its contents is set to fsGroup, and reset on mount if changed on the backend. In 1.4.0, this stopped happening - the recursive chgrp isn't happening, and even new files aren't being created with their gid set to the fsGroup value, they are created with gid=0. This presents an issue with a workload which relies on the gid. Same behavior in 1.5.0, too.
Was the behavior change intentional? I know fsGroup and NFS has always been an odd thing. I was experimenting with using the new ConfigurableFSGroupPolicy feature (fsGroupChangePolicy: "OnRootMismatch") to avoid the recursive chown on every mount for performance reasons, but I still need NEW files to respect fsGroup when created.
To validate, on a new cluster running RKE 1.19.10 I installed csi-powerscale v1.3.0.1 and confirmed fsGroup was working, then upgraded to v1.4.0 with no other changes made in between.