Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using Volume Populator without the need for an additional PVC as source #1129

Open
ansarhun opened this issue Feb 20, 2024 · 4 comments
Open
Labels
enhancement New feature or request

Comments

@ansarhun
Copy link

Describe the feature you'd like to have.

When provisioning a PVC the dataSourceRef refers to a ReplicationDestination and if I try to configure the ReplicationDestination with destinationPVC pointing to the newly created PVC with the dataSourceRef it will hang as both resource will depend on the other.
Add an option where the dataSourceRef can provision the PVC without the need of an another PVC as a source (e.g. the one created by the ReplicationDestination).

What is the value to the end user? (why is it a priority?)

When creating a PVC with a Volume Populator there would be no need to have an additional PVC in place as a source of the new one.
This can be troublesome for GitOps where the ReplicationDestination and PVC is committed to a git repository with the dataSourceRef and because of this the PVC for the ReplicationDestination will remain in the cluster even though it's not needed after the PVC provisioning.

How will we know we have a good solution? (acceptance criteria)

A PVC can be created and provisioned with a dataSourceRef without the need of additional PVC.

Additional context

I'm not sure if my original idea to let the ReplicationDestination point to the PVC with the dataSourceRef could work.
Something like this:

---
apiVersion: volsync.backube/v1alpha1
kind: ReplicationDestination
metadata:
  name: datavol-dest
spec:
  trigger:
    manual: restore-once
  restic:
    repository: restic-config
    destinationPVC: pvc
    copyMethod: Snapshot #Direct
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 256Mi
  dataSourceRef:
    kind: ReplicationDestination
    apiGroup: volsync.backube
    name: "datavol-dest"
@ansarhun ansarhun added the enhancement New feature or request label Feb 20, 2024
@tesshuflower
Copy link
Contributor

Unfortunately, I'm not sure this is possible, assuming I understand your use-case correctly.

Essentially if you're using the VolumePopulator you cannot use this same PVC as the destinationPVC in your replicationdestination as the replicationdestination still needs a PVC to copy to. Steps are essentially this:

  • ReplicationDestination runs a mover job that mounts the destinationPVC (destinationPVC will be created automatically by the replicationdestination if you don't specify it in the spec) and writes to it
  • A volumesnapshot is created of this destination PVC
  • Now the volumepopulator can provision a new PVC (let's call this vp-pvc) which is essentially a PVC from that volumesnapshot.

At this point you can delete your replicationdestination (which will also clean up the destinationPVC if it originally created it) as your vp-pvc is already provisioned

If you are looking to simply do a 1 time replication (such as a restore from restic) then you could look into using copyMode: Direct and not use the volume populator at all. This way the replication using the repicationdestination writes directly to your destinationPVC - and then you can simply use this destination PVC.

@ansarhun
Copy link
Author

Thank you for the quick reply!
Yes that summary is correct, I want to use this for a complete cluster reinstall.
I wanted to go with the volume populator option because:

About removing the ReplicationDestination it seems that the dataSourceRef is an immutable field for PVC and I'm not sure if it could cause any issue if it refers to a non existing resource after it was provisioned kubernetes/kubernetes#119451

If it not possible to provision the PVC directly from the backup (e.g. the restic destination), I will look into using the one of restore.

@ansarhun
Copy link
Author

Would it be possible in this case if the destinationPVC of the ReplicationDestination is the same as the PVC with the volume populator to create a temporary PVC, restore the volume there, rebind the PV and drop the temporary PVC?

@tesshuflower
Copy link
Contributor

About removing the ReplicationDestination it seems that the dataSourceRef is an immutable field for PVC and I'm not sure if it could cause any issue if it refers to a non existing resource after it was provisioned kubernetes/kubernetes#119451

You can remove the replication destination after your volume populator PVC has been populated. Once the PVC goes into bound state, volsync will not try to populate it again, essentially you can think of it as a one time operation.

Would it be possible in this case if the destinationPVC of the ReplicationDestination is the same as the PVC with the volume populator to create a temporary PVC, restore the volume there, rebind the PV and drop the temporary PVC?

I think this is getting overly complex - we might consider having some option to drop the temporary pvc after each replicationdestination sync cycle however? This does mean for repeated syncs to a destination with this option, a full copy of the data would need to be pulled down each time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: No status
Development

No branches or pull requests

2 participants