Follow-up from #6390 (CephFS MDS pinning via VolumeAttributesClass).
The current e2e test only asserts the front-end (the VolumeAttributesClass reference on the PV/PVC object). It does not verify that the pin is actually applied on the CephFS subvolume in the backend.
Backend verification is not straightforward:
ceph fs subvolume info does not report the pin- The pin (
ceph.dir.pin) is set on the subvolume directory (/volumes/<group>/csi-vol-<id>/), while the CSI driver mounts the data subdirectory (.../<uuid>/) as the volume root, so it is not visible from the application pod.
- Asserting the pin requires mounting the whole filesystem in the toolbox and reading
ceph.dir.pin on the subvolume directory.
Alternatively, we could open an RFE for the Ceph project to expose the pin information directly through a command (for example, adding it to the output of ceph fs subvolume info, which today does not report it). This would remove the need to mount the whole filesystem to read ceph.dir.pin, making the backend assertion in e2e significantly simpler.
Follow-up from #6390 (CephFS MDS pinning via VolumeAttributesClass).
The current e2e test only asserts the front-end (the VolumeAttributesClass reference on the PV/PVC object). It does not verify that the pin is actually applied on the CephFS subvolume in the backend.
Backend verification is not straightforward:
ceph fs subvolume infodoes not report the pinceph.dir.pin) is set on the subvolume directory (/volumes/<group>/csi-vol-<id>/), while the CSI driver mounts the data subdirectory (.../<uuid>/) as the volume root, so it is not visible from the application pod.ceph.dir.pinon the subvolume directory.Alternatively, we could open an RFE for the Ceph project to expose the pin information directly through a command (for example, adding it to the output of
ceph fs subvolume info, which today does not report it). This would remove the need to mount the whole filesystem to readceph.dir.pin, making the backend assertion in e2e significantly simpler.