CSI to CSM Operator Migration
Migrating from CSI Operator to CSM Operator
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.
OpenShift Web Console Migration Steps
- Save the CR yaml file of the current CSI driver to preserve the settings (for use in step 6). 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
- 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
- Delete the CSI driver through the CSI Operator in the OpenShift Web Console
- Find the CSI operator under Operators -> Installed Operators
- Select the Dell CSI Operator and find your installed CSI driver under All instances
- Uninstall the CSI Operator in the OpenShift Web Console
- Install the CSM Operator in the OpenShift Web Console
- Search for Dell in the OperatorHub
- Select Dell Container Storage Modules and install
- Install the CSI driver through the CSM Operator in the OpenShift Web Console
- Select Create instance under the provided Container Storage Module API
- Use the CR backup from step 1 to manually map desired settings to the new CSI driver
- 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
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.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.