* e2e: run the CSI cases on kind in CI
The CSI cases have never run in CI. kind has no driver that can take
snapshots, so they were skipped by omission: no label set selects them
and FEATURES is never set.
Add a job that installs the snapshot stack with
hack/install-csi-hostpath.sh and runs them against it, with the
StorageClass pointed at a hostpath definition so the volumes can actually
be snapshotted.
It is a separate job rather than a fifth entry in the existing matrix.
Installing the stack measures at about 3.4 minutes, which every job would
pay, and ResourceFiltering already peaks six minutes under its timeout.
This also keeps a CSI problem from reddening a job that has nothing to do
with CSI.
It runs on the newest three Kubernetes versions. csi-driver-host-path
ships deploy manifests only for recent releases, so the older end of the
matrix has nothing to install.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10644
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
The e2e suite creates both of its StorageClasses from the provider's file
under testdata/storage-class, so running against a cluster whose volumes
need a different provisioner or parameters means editing test data every
other job also reads. On kind that is the only way to get a class a CSI
driver can snapshot.
Take the definition as a flag instead. --storage-class-file and
--storage-class-file-2 name a manifest each, and the suite keeps creating
and deleting what it applied, so nothing adopts resources it did not make.
The class names stay fixed. Every spec refers to e2e-storage-class and
e2e-storage-class-2, and CreateStorageClassFromYaml already takes a name
override, so only the definition needs to vary.
An empty --storage-class-file-2 runs without a second StorageClass, and
the three cases that map between two of them skip with a message saying
how to enable them. Which specs need it cannot be worked out in
BeforeSuite, since the label filter is not visible there yet, so this is
expressed as an opt-out rather than detection.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Migrate VolumeGroupSnapshot API from v1beta2 to v1
Signed-off-by: Prasad Joshi <prajoshi@redhat.com>
* Add changelog
Signed-off-by: Prasad Joshi <prajoshi@redhat.com>
* Detect VolumeGroupSnapshot API version at runtime
Velero hardcoded the VolumeGroupSnapshot (VGS) API version, so VGS backup and
restore failed on clusters that serve a different version than Velero expects.
For example OCP 5.0 serves only groupsnapshot.storage.k8s.io/v1 and OCP 4.22
serves only v1beta1, while Velero targeted a single version and failed with
"no matches for kind" on the others.
Detect the served VGS API version at runtime via the discovery client
(preferring v1 > v1beta2 > v1beta1) and perform all VGS, VGSClass and VGSContent
I/O through the dynamic client, converting to and from the canonical v1 typed
structs. The controller-runtime typed client cannot negotiate versions because
it sends the GVK of the Go type, so the dynamic client is used at the I/O
boundary instead. Owner-reference matching is now version-independent (Kind and
UID), since the CSI controller stamps refs with whatever version the cluster
serves.
This builds on the v1 migration and external-snapshotter client bump from the
previous commits.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
* Add changelog for VGS runtime version detection
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
* docs: VGS supports v1/v1beta2/v1beta1 via runtime detection
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
* Remove superseded changelog for #10600 (covered by #10601)
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
* Use crClient + unstructured for VGS access instead of a dynamic client
Address review feedback: rather than a dedicated VGSClient wrapping
dynamic.Interface + discovery.DiscoveryInterface, perform all VolumeGroupSnapshot
I/O through the existing controller-runtime client with *unstructured.Unstructured.
The object's GVK is stamped to the served version and controller-runtime routes it
via its RESTMapper, giving the same multi-version behavior (v1/v1beta2/v1beta1)
that the typed client cannot.
This removes the extra client plumbing: no constructor signature changes to
NewRestoreFinalizerReconciler or server.go, no Factory DynamicClient/DiscoveryClient
mock churn, and no separate fake client package. The version is resolved from the
client's RESTMapper (preferring v1 > v1beta2 > v1beta1), and the helpers convert
to and from the canonical v1 typed structs.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
---------
Signed-off-by: Prasad Joshi <prajoshi@redhat.com>
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Co-authored-by: Prasad Joshi <prajoshi@redhat.com>
* e2e: add kind VolumeGroupSnapshotClass test data
Velero selects a VolumeGroupSnapshotClass by the
velero.io/csi-volumegroupsnapshot-class label, and csi-driver-host-path
ships no VolumeGroupSnapshotClass at all, so there is nothing for the
selector to find on a kind cluster. Any VolumeGroupSnapshot e2e coverage
needs a class to exist first.
Add the kind entry alongside the existing volume-snapshot-class test
data, following the same layout and naming. Verified against a kind
cluster running external-snapshotter v8.6.0 and csi-driver-host-path:
applying this file and creating a VolumeGroupSnapshot that selects two
labelled PVCs reaches readyToUse with both member snapshots ready.
Nothing applies this file yet. It is a prerequisite for the
VolumeGroupSnapshot specs tracked in #7507, kept separate so the class
can be reviewed on its own.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10582
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
BeforeSuite applies testdata/volume-snapshot-class/<provider>.yaml when
CSI is enabled, and there is no kind.yaml, so the suite fails before any
spec runs and none of the existing CSI tests can run on kind.
This adds a class for csi-driver-host-path. The driver ships its own, but
it lacks the velero.io/csi-volumesnapshot-class label so Velero never
selects it. Nothing sets FEATURES=EnableCSI for kind yet, so no test that
runs today is affected.
Signed-off-by: Sairam Bisoyi <sairamb2007.21@gmail.com>
* Only install and uninstall SC and VSC once for default cluster.
* Install and uninstall SC and VSC for standby cluster on migration case.
* Refactor the StorageClass and VolumeSnapshotClass YAMLs.
* Prettify the e2e_suite_test.go
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
* Add new flag HAS_VSPHERE_PLUGIN for E2E test.
* Modify the E2E README for the new parameter.
* Add the VolumeSnapshotClass for VKS.
* Modify the plugin install logic.
* Modify the cases to support data mover case in VKS.
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
KrishhnaTandGitHub
Sairam BisoyiandGitHub
Xun Jiang
danfengl
Xun Jiang
Xun JiangandXun Jiang
Tiger Kaovilai
Ming Qiu