* e2e: match --features as the comma-separated list it is
--features takes a comma-separated list, but every check for EnableCSI in
the suite compares the whole flag value against the single feature name.
With --features=EnableCSI,EnableAPIGroupVersions none of them match, so a
CSI run quietly behaves as a non-CSI one: BeforeSuite skips installing the
VolumeSnapshotClass, installKibishii picks the provider's plain overlay
rather than its CSI one, and BuildSnapshotCheckPointFromVolumeInfo returns
a checkpoint with EnableCSI false and no snapshot handles, so the CSI
snapshot count is never compared against the expected one.
One site already used strings.Contains instead, which handles a list but
matches any feature whose name merely starts with this one, and misses a
value that differs only in case.
Add FeatureEnabled, which splits on commas and compares each entry whole
and case-insensitively, and route all eleven call sites through it. The
table test covers the list, case and prefix shapes that the two previous
idioms each got wrong.
hack/test.sh listed only ./pkg/..., ./internal/... and ./cmd/..., so
nothing under test/ was ever unit tested and this table would not have run
in CI. Add ./test, which holds the suite's shared types and nothing that
needs a cluster. The e2e suites live in subpackages and stay unlisted.
Found while reviewing the kind-csi mapping in #10657, which copied the
EqualFold form from the Azure and AWS branches beside it.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10661
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
e2e: run the RetainPV case too, and move the predicate beside the mapping
The RetainPV case was left out of the matrix on the assumption that it
needed checking first. It did not: it passes. Run on kind with
EnableCSI, Ran 1 of 70 Specs in 354 seconds, 1 passed, installing from
overlays/sc-reclaim-policy/kind-csi and taking two real CSI snapshots of
Kibishii's PVCs. So drop the exclusion rather than add a second row, and
the label becomes plain Basic && Snapshot, which selects the plain
snapshot case and the retained-PV one.
That overlay is the other half of the Kibishii change, and nothing
exercised it until now.
KibishiiVolumesAreHostPath moves from test/types.go to sit beside
installKibishii, since it is the inverse of that function's Kind branch
and the two have to agree on what enabling CSI means. Each now points at
the other in a comment. There is no import cycle: the kibishii package
already dot-imports test, and every call site already dot-imports
kibishii.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: point Kibishii at the kind-csi overlay when CSI is enabled
installKibishii maps the cloud platform to a Kibishii overlay directory
and already swaps Azure and AWS for their CSI variants when EnableCSI is
set. Kind has no such branch, so a CSI run on kind gets the plain kind
overlay, whose StorageClass provisions with rancher.io/local-path. Those
PVs are hostPath volumes and Velero skips them for both CSI snapshots
and PodVolumeBackups, which is why the snapshot cases are guarded off on
kind today.
Add the kind branch alongside the other two, and move KIBISHII_COMMIT to
the commit that adds the overlay. The pin delta is additive: the only
difference between the two trees is the new kind-csi directory and its
reclaim-policy overlay, so the plain kind overlay that run-e2e-test uses
still builds on rancher.io/local-path.
Nothing selects a Kibishii case under EnableCSI yet, so this changes no
observable behaviour on its own. Narrowing the kind guards and adding a
label set to the CSI job follow separately.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10657
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
This commit makes change to the code, scripts and some template files to
reflect the change of the org after donation to CNCF.
The files under "/site" "/changelogs" and "/design" are deliberately
excluded in this change. I'll make follow up changes in these
directories when needed.
Signed-off-by: Daniel Jiang <daniel.jiang@broadcom.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>
* e2e: add VolumeGroupSnapshot coverage
Velero groups PVCs that share a label into one VolumeGroupSnapshot, but
nothing in the e2e suite exercises that path, so a regression in it would
go unnoticed.
Add a case alongside the other backup-volume-info CSI cases. It creates
two PVCs carrying the grouping label the Velero server defaults to,
velero.io/volume-group, and asserts that the backup's volume info reports
the same VolumeGroupSnapshotHandle for both. One shared handle is what
distinguishes a group snapshot from the volumes having been snapshotted
one at a time, which is the part worth asserting.
The suite installs a VolumeGroupSnapshotClass beside the
VolumeSnapshotClass and removes it afterwards. Only providers that have
the test data get one, so the case runs where a class exists and is
skipped elsewhere, in the same way the existing CSI cases are skipped
when the CSI feature is off. Removing it afterwards matters: Velero
cannot choose between two classes carrying the selector label, and fails
every VolumeGroupSnapshot backup on that cluster if one is left behind.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10598
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: log the VolumeGroupSnapshotHandle the VGS case asserts on
CSISnapshotInfo is a pointer, so printing the VolumeInfo with %+v emits
CSISnapshotInfo:0x270e179b4900 and nothing about the handle. This case
exists to check that every volume in the group reports the same handle,
so a failure in CI currently gives no way to see what the handles
actually were.
Print the handle per PVC alongside the existing line. The other
backup-volume-info cases print the same way; changing those belongs in
its own change.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* 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>
Rename the local pvcBulder variable to pvcBuilder in the k8s test
helpers. No behavior change.
Signed-off-by: Pranjal Manhgaye <manhgayepranjal@gmail.com>
* refactor: use k8s.io/api well-known label constants
Several well-known Kubernetes label strings were hardcoded across the
codebase instead of using the constants already exported by
k8s.io/api/core/v1, which is an existing dependency:
"kubernetes.io/hostname" -> corev1api.LabelHostname
"kubernetes.io/os" -> corev1api.LabelOSStable
"topology.kubernetes.io/zone" -> corev1api.LabelTopologyZone
The local kube.NodeOSLabel and zoneLabel consts, which duplicated the
upstream values verbatim, are now defined in terms of the upstream
constants rather than repeating the literal. Both are kept: NodeOSLabel
is exported and referenced from four packages alongside NodeOSLinux and
NodeOSWindows, which have no upstream equivalent, and zoneLabel sits
beside the deprecated-label fallback it is compared against.
No functional change - every replacement is a constant with an identical
value.
Signed-off-by: Harshit saini <harshitsaini1188@gmail.com>
* Add changelog for #10279
Signed-off-by: Harshit saini <harshitsaini1188@gmail.com>
* Cover the selected-node path in createRestorePod
TestCreateRestorePod only exercised selectedNode == "", so the branch
that pins the restore pod to a node was never executed. Add a case with
a selected node and assert the resulting pod carries the hostname label
in its node selector.
Signed-off-by: Harshit saini <harshitsaini1188@gmail.com>
* Also use constants for the arch and deprecated zone labels
Extends the same replacement to the two remaining well-known labels
raised on the issue:
"kubernetes.io/arch" -> corev1api.LabelArchStable
"failure-domain.beta.kubernetes.io/zone" -> corev1api.LabelFailureDomainBetaZone
zoneLabelDeprecated in item_backupper.go was the last local const still
repeating a literal that upstream already exports, so the zone pair now
reads consistently against k8s.io/api. The deprecation note upstream
applies to the label itself, not the constant; Velero reads that label
deliberately as the fallback for PVs created before the topology labels
existed.
Signed-off-by: Harshit saini <harshitsaini1188@gmail.com>
---------
Signed-off-by: Harshit saini <harshitsaini1188@gmail.com>
Change errors.Cause to errors.Is, because github.com/cockroachdb/errors
New() function create a error with error stack with depth 1, but
github.com/pkg/errors's New() function create error with no depth.
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
* Remove Restic references from E2E tests and CI workflows
Rename all Restic-labeled tests to FSBackup since they test the file
system backup path, not Restic specifically. Remove dead Restic code
including VeleroUpgrade, UpdateVeleroDeployment, UpdateNodeAgent,
IsSupportUploaderType, UseResticIfFSBackup, and UploaderTypeRestic —
the server now rejects Restic as an unsupported uploader type.
Fixes#9482
Signed-off-by: Joseph <jvaikath@redhat.com>
* Add changelog for PR #9867
Signed-off-by: Joseph <jvaikath@redhat.com>
---------
Signed-off-by: Joseph <jvaikath@redhat.com>
Remove 'self' from MIGRATE_FROM_VELERO_VERSION.
* Need to modify the BYOT case to specify MIGRATE_FROM_VELERO_VERSION.
Remove the CSI plugin installation check for no older than v1.14
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
Fix GetResourceWithLabel's bug: labels were not applied.
Add workOS for deployment and pod creationg.
Add OS label for select node.
Enlarge the context timeout to 10 minutes. 5 min is not enough for Windows.
Enlarge the Kibishii test context to 15 minutes for Windows.
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
It failed with fetching the wrong VolumeInfo. Correct it.
Add AdditionalBSL label for applied cases.
Remove not needed default BSL kibishii test for additional bsl case.
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
PVB and PVR used to print related pod namespace in output.
In v1.17, the behavior changed. Use backup or restore name to filter them.
Shorten the timeout context from 1h to 5m, because AWS was not covered anymore.
Remove an used if branch for vSphere.
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
- Add --server-priority-class-name and --node-agent-priority-class-name flags to velero install command
- Configure data mover pods (PVB/PVR/DataUpload/DataDownload) to use priority class from node-agent-configmap
- Configure maintenance jobs to use priority class from repo-maintenance-job-configmap (global config only)
- Add priority class validation with ValidatePriorityClass and GetDataMoverPriorityClassName utilities
- Update e2e tests to include PriorityClass testing utilities
- Move priority class design document to Implemented folder
- Add comprehensive unit tests for all priority class implementations
- Update documentation for priority class configuration
- Add changelog entry for #8883
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
remove unused test utils
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
feat: add unit test for getting priority class name in maintenance jobs
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
doc update
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
feat: add priority class validation for repository maintenance jobs
- Add ValidatePriorityClassWithClient function to validate priority class existence
- Integrate validation in maintenance.go when creating maintenance jobs
- Update tests to cover the new validation functionality
- Return boolean from ValidatePriorityClass to allow fallback behavior
This ensures maintenance jobs don't fail due to non-existent priority classes,
following the same pattern used for data mover pods.
Addresses feedback from:
https://github.com/vmware-tanzu/velero/pull/8883#discussion_r2238681442
Refs #8869
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
refactor: clean up priority class handling for data mover pods
- Fix comment in node_agent.go to clarify PriorityClassName is only for data mover pods
- Simplify server.go to use dataPathConfigs.PriorityClassName directly
- Remove redundant priority class logging from controllers as it's already logged during server startup
- Keep logging centralized in the node-agent server initialization
This reduces code duplication and clarifies the scope of priority class configuration.
🤖 Generated with [Claude Code](https://claude.ai/code)
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
refactor: remove GetDataMoverPriorityClassName from kube utilities
Remove GetDataMoverPriorityClassName function and its tests as priority
class is now read directly from dataPathConfigs instead of parsing from
ConfigMap. This simplifies the codebase by eliminating the need for
indirect ConfigMap parsing.
Refs #8869🤖 Generated with [Claude Code](https://claude.ai/code)
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
refactor: remove priority class validation from install command
Remove priority class validation during install as it's redundant
since validation already occurs during server startup. Users cannot
see console logs during install, making the validation warnings
ineffective at this stage.
The validation remains in place during server and node-agent startup
where it's more appropriate and visible to users.
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-Authored-By: Claude <noreply@anthropic.com>
* Refactor backup volume info retrieval and snapshot checkpoint building in e2e tests
Signed-off-by: Priyansh Choudhary <im1706@gmail.com>
log backup volume info retrieval and snapshot checkpoint building
Signed-off-by: Priyansh Choudhary <im1706@gmail.com>
Add error handling for volume info retrieval in backup tests
Signed-off-by: Priyansh Choudhary <im1706@gmail.com>
Add error handling for volume info retrieval in backup tests
Signed-off-by: Priyansh Choudhary <im1706@gmail.com>
* Update snapshot checkpoint building to use DefaultKibishiiWorkerCounts
Signed-off-by: Priyansh Choudhary <im1706@gmail.com>
---------
Signed-off-by: Priyansh Choudhary <im1706@gmail.com>
* Add support for pod labels and service account annotations in Velero configuration
Signed-off-by: Priyansh Choudhary <im1706@gmail.com>
* Refactor Velero configuration to use string types for pod labels and service account annotations
Signed-off-by: Priyansh Choudhary <im1706@gmail.com>
* Please notice only Kibishii workload support Windows test,
because the other work loads use busybox image, and not support Windows.
* Refactor CreateFileToPod to support Windows.
* Add skip logic for migration test if the version is under 1.16.
* Add main in semver check.
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
KrishhnaTandGitHub
Daniel JiangandGitHub
Xun Jiang/Bruce JiangandGitHub
Pranjal Manhgaye
harshit sainiandGitHub
Xun Jiang
Joseph Antony VaikathandGitHub
Lyndon-Li
lyndon-liandGitHub
Tiger KaovilaiandClaude
Shubham Pampattiwar
Priyansh ChoudharyandGitHub
Wenkai Yin(尹文开)andGitHub
Matthieu MORELandGitHub