CSI to CSM Operator Migration
CR Sample Files
CSI Operator | CSM Operator | |
---|---|---|
PowerScale | isilon_v270_k8s_127.yaml | storage_csm_powerscale_v280.yaml |
PowerMax | powermax_v270_k8s_127.yaml | storage_csm_powermax_v280.yaml |
PowerStore | powerstore_v270_k8s_127.yaml | storage_csm_powerstore_v290.yaml |
Unity XT | unity_v270_k8s_127.yaml | storage_csm_unity_v280.yaml |
PowerFlex | vxflex_v270_k8s_127.yaml | storage_csm_powerflex_v290.yaml |
NOTE: Sample files refer to the latest version for each platform. If you do not want to upgrade, please find your preferred version in the csm-operator repository.
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
- 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
- Ex: spec.driver.fsGroupPolicy in PowerMax 2.6 for CSI Operator maps to spec.driver.csiDriverSpec.fSGroupPolicy in PowerMax 2.10 for 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
- 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
- Ex: spec.driver.fsGroupPolicy in PowerMax 2.6 for CSI Operator maps to spec.driver.csiDriverSpec.fSGroupPolicy in PowerMax 2.10 for 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.