Skip to content

Commit

Permalink
populators doc updates after review
Browse files Browse the repository at this point in the history
Signed-off-by: Shelly Kagan <skagan@redhat.com>
  • Loading branch information
ShellyKa13 committed Jun 28, 2023
1 parent 0f94657 commit 745e287
Showing 1 changed file with 32 additions and 8 deletions.
40 changes: 32 additions & 8 deletions doc/cdi-populators.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,13 +7,13 @@ What are [populators](https://kubernetes.io/blog/2022/05/16/volume-populators-be
## Introduction
CDI volume populators are CDIs implementation of populating PVCs by importing/uploading/cloning data utilizing the new `dataSourceRef` field. New controllers and custom resources for each population method were introduced.

**Values of the new API?**
* Native synchronization with Kubernetes - this is kubernetes way of populating PVCs. Once PVC is bound we know it is populated (So far PVC was bound the moment the datavolume created it and the population progress was monitored via the datavolume)
* Use PVCs directly and get them populated without datavolumes mitigation.
**Benefits of the new API**
* Native synchronization with Kubernetes - this is Kubernetes way of populating PVCs. Once PVC is bound we know it is populated (Before introducing populators, the PVC was bound the moment the datavolume created it, and the population progress was monitored via the datavolume)
* Use PVCs directly and get them populated without datavolumes mediation.
* Can use one population definition for multiple PVCs - create 1 CR defining population source and use it for any PVC.
* Better compatibility with existing backup solutions. Using PVC alone should solve all backup issues. Using datavolumes with populators solves most, for example Metro DR and [Gitops](https://www.redhat.com/en/topics/devops/what-is-gitops#:~:text=GitOps%20uses%20Git%20repositories%20as,set%20for%20the%20application%20framework.) - datavolume manifest will be applied, the datavolume will create the PVC that will bind immediately to the PV waiting for it.
* Better compatibility with integration with [Kubevirt](https://github.com/kubevirt/kubevirt) and existing backup solutions, using VMs with PVCs using populators and VMs with datavolumetemplates.
* Integration with [Kubevirt](https://github.com/kubevirt/kubevirt) with WFFC storage class is simpler not requiring [doppelganger pod](https://github.com/kubevirt/kubevirt/blob/main/docs/localstorage-disks.md#the-problem) for the start of the VM.
* Better compatibility with existing backup solutions and [Kubevirt](https://github.com/kubevirt/kubevirt) VMs with PVCs using populators and VMs with datavolumetemplates.
* Integration with [Kubevirt](https://github.com/kubevirt/kubevirt) with WaitForFirstConsumer(WFFC) storage class is simpler not requiring [doppelganger pod](https://github.com/kubevirt/kubevirt/blob/main/docs/localstorage-disks.md#the-problem) for the start of the VM.


## Using the populators
Expand All @@ -36,7 +36,7 @@ spec:
User can create a CR and PVCs specifying the CR in the `DataSourceRef` field and those will be handled by the matching populator controller.

#### Import
Example for PVC which will be handled by the import populator:
Example for PVC which use the VolumeImportSource above that will be handled by the import populator:
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
Expand All @@ -59,10 +59,34 @@ The controller will create a matching temporary PVC with the appropriate annotat
Once the temporary PVC population is done, the PV will be rebound to the original PVC completing the population process.

#### Upload
For upload need to follow the same guidelines as describe in the [upload doc](upload.md) but instead of creating a data volume you can create VolumeUploadSource CR and PVC similar to the import examples in this doc.
Example of VolumeUploadSource and a PVC that will be handled by the upload populator:
```yaml
apiVersion: cdi.kubevirt.io/v1beta1
kind: VolumeUploadSource
metadata:
name: my-upload-source
spec:
contentType: kubevirt
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
dataSourceRef:
apiGroup: cdi.kubevirt.io
kind: VolumeUploadSource
name: my-upload-source
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
```
After creating the VolumeUploadSource and PVC, you can start the upload to the pvc as describe in the [upload doc](upload.md).

#### Clone
Same for clone very similar API:
Example of VolumeCloneSource and a PVC that will be handled by the clone populator:
```yaml
apiVersion: cdi.kubevirt.io/v1beta1
kind: VolumeCloneSource
Expand Down

0 comments on commit 745e287

Please sign in to comment.