Skip to content

Commit

Permalink
initial commit
Browse files Browse the repository at this point in the history
  • Loading branch information
OsamaKhan220 committed Jan 20, 2025
0 parents commit d82e622
Show file tree
Hide file tree
Showing 6 changed files with 138 additions and 0 deletions.
6 changes: 6 additions & 0 deletions Chart.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
apiVersion: v2
name: pvc-copy-tool
description: A job for copying contents from one PV to another
type: application
version: 1.0.0
appVersion: "1.0.0"
76 changes: 76 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
# Pvc Copy Tool

The pvc copy tool is designed to rsync the contents of one PersistentVolume (PV) to a newly created PersistentVolumeClaim (PVC). This tool is especially useful when migrating PersistentVolumes to a new StorageClass or when you need to resize a PV that belongs to a StorageClass that doesn’t support resizing.

The tool employs a workaround for reclaiming PVs, which is necessary to handle ReadWriteOnce (RWO) PVs. If you're working with a ReadWriteMany (RWX) PV, you can directly run an rsync job and attach the Job-Pod to the existing PVC—there's no need to create a new PVC.

Use Cases
- Migrate PVs to different StorageClasses.
- Resize PVs that are using StorageClasses that don’t support resizing.
- Copy data from one PV to another, maintaining data integrity.

## How to Use

### Step-by-Step Process:
1. Identify the PV to Copy: Find the PersistentVolume (PV) you wish to copy.

2. Change PV Reclaim Policy: Update the persistentVolumeReclaimPolicy of the PV to Retain.

3. Get PV Name: Retrieve the name of the PV you want to copy.

4. Deploy the Helm Chart: Apply the provided Helm chart, specifying:
- The name of the PV in the values.yaml file.
- The name, storage class, and size of the new PVC.

5. Delete the Original PVC: Delete the old PVC and remove the claimRef from the source PV.

6. Monitor the Job: The job will begin copying data from the original PV to the new PVC. The logs may show warnings about the inability to preserve the original file owners, but this is a known limitation due to OpenShift security settings and can be ignored.

7. Cleanup: After the data has been copied, the new PVC will be available, and you can remove the Helm chart.

## Rebinding the PV to the Original PVC
Once the data has been copied and the Job has been deleted, you can rebind the PV to the original PVC name. If you're using an inflexible operator, like openshift-image-operator, you may need to perform a "hot swap" with the PVC for the PV to be properly bound.

### Steps to Rebind:
1. Check New PV: Ensure the new PV has the persistentVolumeReclaimPolicy set to Retain and that the access mode matches the PVC you intend to bind it to.

2. Remove ClaimRef: Delete the PVC bound to the new PV and remove the ClaimRef from the PV.

3. Prepare PVC YAML: Copy the YAML definition for the PVC you plan to bind the PV to. Paste it into a file or use OpenShift's "Import YAML" dialog.

4. Update PVC YAML: Update the volumeName in the PVC YAML to point to your new PV.

5. Delete PVC and Pod: Delete the application's PVC and pod. Then quickly apply the updated PVC YAML to bind the new PV to the PVC.

6. Confirm Application: If successful, your application should now be using the newly copied PV, which is on the new StorageClass.

## Example Helm Chart Deployment for One-Off Job
To deploy the tool as a one-off job, you can use the following example Helm chart configuration:

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: pvc-copy-tool
namespace: argocd
spec:
destination:
namespace: <target-namespace>
server: https://kubernetes.default.svc
source:
path: pvc-copy-tool
repoURL: ssh://[email protected]:stakater/pvc-copy-tool.git
targetRevision: master
helm:
parameters:
- name: oldPvName
value: "<target-pv>"
- name: newPvcName
value: "image-registry-storage-clone"
- name: newPvcStorageClass
value: ""
- name: newPvcSize
value: "100Gi"
```
By following this process, you can effectively copy data from an existing PersistentVolume to a new PVC, ensuring the migration to new StorageClasses or resizing needs are met.
26 changes: 26 additions & 0 deletions templates/copy-job.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
apiVersion: batch/v1
kind: Job
metadata:
name: pvc-copy-tool
spec:
template:
spec:
containers:
- name: cp
image: busybox:1.36-glibc
command: ["/bin/sh", "-c", "--"]
args: ["cp -a /old-pv/* /new-pv/"] # Note that this has the limitation of not copying hidden folders/files. Busybox does not support trailing slash syntax to copy the contents of a folder.
volumeMounts:
- name: old-pv
mountPath: /old-pv
- name: new-pv
mountPath: /new-pv
volumes:
- name: old-pv
persistentVolumeClaim:
claimName: reclaimer
- name: new-pv
persistentVolumeClaim:
claimName: {{ .Values.newPvcName }}
restartPolicy: OnFailure
backoffLimit: 4
11 changes: 11 additions & 0 deletions templates/pvc-destination.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: {{ .Values.newPvcName }}
spec:
storageClassName: {{ .Values.newPvcStorageClass }}
accessModes:
- ReadWriteMany
resources:
requests:
storage: {{ .Values.newPvcSize }}
12 changes: 12 additions & 0 deletions templates/pvc-reclaimer.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: reclaimer
spec:
volumeName: {{ .Values.oldPvName }}
storageClassName: {{ .Values.oldStorageClass }}
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
7 changes: 7 additions & 0 deletions values.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@

oldPvName: "old-pvc"

newPvcName: "pvc-copy"
newPvcStorageClass: '""'
newPvcSize: "100Gi"

0 comments on commit d82e622

Please sign in to comment.