CSI to CSM Operator Migration
Migration Steps
- Save the CR yaml file of the current CSI driver to preserve the settings. Use the following commands in your cluster to get the CR:
kubectl -n <namespace> get <CRD_kind>
kubectl -n <namespace> get <CRD_kind>/<CR_name> -o yaml
Example for CSI Unity:
kubectl -n openshift-operators get CSIUnity
kubectl -n openshift-operators get CSIUnity/test-unity -o yaml
- Map and update the settings from the CR in step 1 to the relevant CSM Operator CR (found in csm-operator repository).
- As the yaml content may differ, ensure the values held in the step 1 CR backup are present in the new CR before installing the new driver. CR Samples for CSI Operator and CSM Operator can be used to compare and map the differences in attributes.
- Ex: spec.driver.fsGroupPolicy in CSI Operator maps to spec.driver.csiDriverSpec.fSGroupPolicy in CSM Operator
- As the yaml content may differ, ensure the values held in the step 1 CR backup are present in the new CR before installing the new driver. CR Samples for CSI Operator and CSM Operator can be used to compare and map the differences in attributes.
- Retain (or do not delete) the secret, namespace, storage classes, and volume snapshot classes from the original deployment as they will be re-used in the CSM operator deployment
- Uninstall the CR from the CSI Operator
kubectl delete <driver_type>/<driver_name> -n <driver_namespace>
- Uninstall the CSI Operator itself
- Instructions can be found here
- Install the CSM Operator
- Instructions can be found here
- Install the CR updated in step 2
- Instructions can be found here
NOTE: Uninstallation of the driver and the Operator is non-disruptive for mounted volumes. Nonetheless you can not create new volume, snapshot or move a Pod.
Testing
To test that the new installation is working, please follow the steps outlined here for your specific driver.