-
Notifications
You must be signed in to change notification settings - Fork 31
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
[WIP] VM Object graph: Include backend PVC #321
base: main
Are you sure you want to change the base?
Conversation
A VM might use a backend PVC to persistently store its state. This volume is not included in the VM's spec, thus being ignored by our object graph. This commit updates the VM object graph by including this PVC if necessary. Signed-off-by: Alvaro Romero <[email protected]>
Signed-off-by: Alvaro Romero <[email protected]>
This commit updates the following: * Enables VMPersistentState feature gate in kubevirt config. * Sets vmStateStorageClass to the default storage class in kubevirt config. This fulfill the prerequisites so our func tests can work with VMs using persistent backend PVCs. Signed-off-by: Alvaro Romero <[email protected]>
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@ShellyKa13 @mhenriks so this is failing because before Kubevirt 1.3 the accessMode for the backend storage PVC was hardcoded as rwx. We are usign rook-ceph so no rwx available for filesystem volumes. Would it be appropriate to update Kubevirt to 1.3.0 here https://github.com/kubevirt/kubevirt-velero-plugin/blob/main/hack/config.sh#L20 to make this work? Any specific reason to keep using 1.1? |
@alromeros you can definitely bump the used kubevirt version to 1.3 |
Nice. If we prefer to bump it to v1.4 I'm also ok with it. v1.3 uses the legacy backend storage PVC naming which can be predictably built while v1.4 uses the current labeling method. This PR supports both but testing this newest logic is more interesting imo. |
yes sure why not |
This change is needed so we can create backend PVCs without RWX access mode. Signed-off-by: Alvaro Romero <[email protected]>
695993a
to
faa8983
Compare
What this PR does / why we need it:
This PR updates the VM object graph logic so the persistent VM state PVC is included during backup and restore operations when necessary.
Recent changes in kubevirt have significantly changed the backend PVC logic. This PR aims to maintain compatibility between different kubevirt versions by supporting both the older behavior (where the PVC name was predictable) and the newer behavior (where the PVC name is randomly generated and identified via labels).
This PR also updates the build scripts to enable testing of backend volumes, mainly by enabling the required feature gate and defining the vmStateStorageClass.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes # https://issues.redhat.com/browse/CNV-54911
Special notes for your reviewer:
Release note: