mirror of
https://github.com/vmware-tanzu/velero.git
synced 2026-10-22 14:23:00 +00:00
KrishhnaTandGitHub
1342339994
Run the E2E test on kind / setup-test-matrix (push) Failing after 7s
e2e-test-kind.yaml / extract (push) Failing after 14s
Run the E2E test on kind / get-go-version (push) Failing after 9m53s
Run the E2E test on kind / build (push) Skipped
Run the E2E test on kind / run-e2e-test (push) Skipped
push.yml / extract (push) Failing after 10s
Main CI / get-go-version (push) Failing after 10m23s
Main CI / Build (push) Skipped
Scorecard supply-chain security / Scorecard analysis (push) Skipped
* e2e: verify CSI snapshots on kind Four snapshot cases cannot run on kind today. The backup itself succeeds and the volume info lists the snapshots, but verification fails with "Cloud provider kind is not valid": getProvider knows aws, vsphere, gcp and azure, and CheckSnapshotsInProvider exempts only vanilla-zfs, so kind falls through to a cloud lookup it has no API for. Check kind in the cluster instead. A backup's VolumeSnapshotContents exist only briefly while it is being created, so they cannot be counted afterwards the way the cloud providers count snapshots; what Velero recorded in the backup's volume info can be, one ready CSI snapshot per volume. That is a weaker statement than the cloud checks make, since it says the snapshots were taken and reported ready rather than that they still exist in the storage provider. A backup expected to have none left, after its deletion, is checked the other way round: nothing for it may remain in the cluster, which reuses CheckVolumeSnapshotCR. BuildSnapshotCheckPointFromVolumeInfo only collected those snapshot handles for AWS and Azure, so on kind the checkpoint arrived with no handles and EnableCSI false even with FEATURES=EnableCSI. Include kind. This does not remove any of the CloudProvider == Kind skips; they need Kibishii to offer a CSI StorageClass for kind as well. Signed-off-by: krishhna24 <krishhnatupedev@gmail.com> * Add changelog for #10593 Signed-off-by: krishhna24 <krishhnatupedev@gmail.com> * e2e: check the snapshot handles rather than their count Comparing the number of recorded snapshots against the number expected cannot fail. BuildSnapshotCheckPointFromVolumeInfo already returns an error when a volume is not ready to use, and again when the counts do not match, and it appends to the list in that same loop, so the length is settled before the check is reached. It does not look at the handle it recorded, so a volume reported ready with an empty snapshot handle passes today. Check that instead, which is the difference between Velero saying a snapshot was taken and something having been provisioned. Signed-off-by: krishhna24 <krishhnatupedev@gmail.com> --------- Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>