Description of problem:

There's no procedure to migrate the PVCs to new ones or new storageclass.

Example of use case: Forceful need to migrate to a new datastore.

How it works

The storage in DevSpaces is managed by the `devworkspaceoperatorconfigs`, this CR has a configurable value under `.config.workspace.pvcName`.

If `pvcName` is empty, it defaults to `claim-devworkspace`.

This `pvcName` is applied to all the `DevWorkspaces` with persistent storage configured. If the PVC exists in the namespace, it binds the deployment of the workspace to the PVC. If it does not exist, it creates it.

Workarounds

Based on that behavior, the operation could be accomplished by:

• Automated way:

1. Stop all the DevWorkspaces.
2. Performing MTC StorageClass conversion for the storageclassess the PVCs the DevSpaces operator is using.
3. Edit the `devworkspaceoperatorconfigs` CR and set the `.config.workspace.pvcName` key to `claim-devworkspace-new` (as it will be the name convention followed by MTC StorageClass conversion.
4. Start all the DevWorkspaces.

After step 4, all the DevWorkspaces should be using their new PVC respectively, but they will point to the PVC `claim-devworkspace-new`.

• Semi-automated way:

(can be done with something like the command below, please test it before sharing it with customer)

1. Stop all the DevWorkspaces.
2. Performing MTC StorageClass conversion for the storageclassess the PVCs the DevSpaces operator is using.
3. Put the *new* PVs on Retained:

```
for i in $(oc get pv --no-headers|grep claim-devworkspace-new|awk

{'print $1'}); do oc patch pv/"$i" -p '{"spec":"persistentVolumeReclaimPolicy":"Retain"}}';echo $i>>modifiedPVS.yaml; done
```

4. Take a backup of the YAML of all the *new* DevWorkspace PVCs:

```
>>> ELABORATING COMMAND
```

5. Delete all the PVCs in the devworkspaces projects (both new and old):

```
>>> ELABORATING COMMAND
```

6. Edit the YAML backup of the *new* PVCs so they are all named `claim-devworkspace`:

```
>>> ELABORATING COMMAND
```

7. Create all the edited PVCs:

```
oc apply -f modifiedPVS.yaml
```

8. Clean the ClaimRef of all the *new* PVs.

```
for i in $(oc get pv --no-headers|grep claim-devworkspace-new |awk {'print $1'}

); do oc patch pv/$i -p '{"spec":{"claimRef":null}}';done
```

9. Start all the DevWorkspaces.

This the cleanest way to do the migration as of now.

• Manual way (B):

1. Stop all the DevWorkspaces.
2. Create a new PVC in each DevWorkspace namespace using the new storageclass.
3. [Migrate the data from the old PVC to the new one](https://access.redhat.com/solutions/5794841).
4. Edit the `devworkspaceoperatorconfigs` CR and set the `.config.workspace.pvcName` key to `claim-devworkspace-new` (as it will be the name convention followed by MTC StorageClass conversion.
5. Start all the DevWorkspaces.

This will end on having all the PVCs with a different name and many manual tasks.
 

Actual results:

Using MTC for the migration results on a deadloop because one of the storageclass conversion steps is replacing the PVC on the deployment it belongs to, but it is automatically replaced by the previous name by the Che controller, migration cannot be accomplished at all.

Expected results:

Having clear and as painless as possible steps to do a storage migration for DevSpaces.

Reproducibility (Always/Intermittent/Only Once):

Always

Acceptance criteria: 

Definition of Done:

Build Details:

Additional info (Such as Logs, Screenshots, etc):

 

 *