[manila-csi-plugin] CephFS adapter missing staticVolume parameter for ceph-csi compatibility

What happened:

The Manila CSI CephFS share adapter sends provisionVolume: "false" in the volume context to indicate a statically provisioned volume to the ceph-csi node plugin. However, ceph-csi introduced a volume ID format validator in e2a1f6e that rejects volume IDs not matching the ceph-csi internal format (^[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[a-zA-Z0-9\-\_]+$).

Manila CSI passes Manila share UUIDs as volume IDs (e.g. fee6cec9-988a-45fd-b01d-dc1f5e562104), which don't match this format. The format check is skipped when IsStaticVol() returns true, but that function checks for staticVolume: "true" in the volume attributes — not provisionVolume: "false".

The result is that NodeStageVolume fails with: volumeID has an unexpected format.

What you expected to happen:

Manila CSI volumes should mount successfully with ceph-csi regardless of the volume ID format, since they are statically provisioned volumes.

How to reproduce:

Deploy Manila CSI with CephFS protocol using ceph-csi >= v3.14.0 as the forwarding node plugin. Create a CephFS PVC — the pod will fail to start with the format validation error.

Fix:

Add staticVolume: "true" to the CephFS volume context alongside the existing provisionVolume: "false". The staticVolume parameter is simply ignored by older ceph-csi versions that don't recognize it, making this change backwards compatible.

Environment:

• cloud-provider-openstack version: master
• ceph-csi version: v3.14.0+

Find the Manila CSI CephFS share adapter code that adds provisionVolume: "false" to the volume context, then inspect the surrounding volume-context construction. Add staticVolume: "true" alongside it and verify that CephFS volumes mount with ceph-csi v3.14.0 or newer while remaining compatible with older versions.