rook: Bug: CSI subvolumegroup is not created by rook automatically
- Bug Report In continuation of https://github.com/rook/rook/issues/4006 Rook does not create the expected subvolumegroup called “csi” when creating a new filesystem.
Deviation from expected behavior:
csi driver is not creating the subvolumegroup called csi
Expected behavior: csi driver should create the subvolumegroup called csi
How to reproduce it (minimal and precise):
Create a CephFilesystem with the following: https://github.com/rook/rook/blob/master/cluster/examples/kubernetes/ceph/filesystem.yaml
Afterwards, create a storageclass “rook-cephfs” which makes use the filesystem called “myfs” created above. https://github.com/rook/rook/blob/master/cluster/examples/kubernetes/ceph/csi/cephfs/storageclass.yaml
Lastly, create the PVC and test deployment https://github.com/rook/rook/blob/master/cluster/examples/kubernetes/ceph/csi/cephfs/kube-registry.yaml
File(s) to submit:
All files as per links above.
Environment:
- OS (e.g. from /etc/os-release): Centos 7
- Kernel (e.g.
uname -a): - Cloud provider or hardware configuration:. VMWare bare metal
- Rook version (use
rook versioninside of a Rook Pod): version 1.4 - Storage backend version (e.g. for ceph do
ceph -v): ceph/ceph:v15.2.4 - Kubernetes version (use
kubectl version): 1.8 - Kubernetes cluster type (e.g. Tectonic, GKE, OpenShift): Kubernetes on bare metal
- Storage backend status (e.g. for Ceph use
ceph healthin the [Rook Ceph toolbox]. Health ok
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 35 (9 by maintainers)
I think the root case is that your filesystem was recreate, cephfs-csi stores a bool variable in memory for each cluster to mark whether a subvolumegroup has been created, cephfs-csi corresponds to a cluster via the clusterID field in StorageClass, which is set to the namespace of the cephcluster in rook, so when the CephFilesystem is rebuilt in the same namespace and StorageClass is recreated, in cephfs-csi the variable for the cluster is true, so there is no attempt to recreate the subvolumegroup
@Madhu-1 I will check, but can only do next week.