- Fix 'dataudownload' typo in DataDownload warning log message
(data_download_controller.go:696)
- Fix 'datadownlad' misspelled structured log field key to 'datadownload'
(data_download_controller.go:700) - this caused the log field to be
unqueryable by the correct key name
- Fix 'retrieveable' -> 'retrievable' in BackupRepository maintenance
status messages (maintenance.go:354, 417)
- Update corresponding test assertion to match corrected string
(maintenance_test.go:792)
(cherry picked from commit 0ebb6e9e06)
Co-authored-by: shellyco-code <shellyco-code@users.noreply.github.com>
Co-authored-by: kaovilai <11228024+kaovilai@users.noreply.github.com>
* Fix ResourceDeletionStatusTracker key Kind mismatch in terminating-namespace wait (#9987)
EnsureNamespaceExistsAndIsReady wrote the tracker key with namespace.Kind
(getNamespace() sets Kind=Namespace) but read it with clusterNS.Kind
(client.Get strips TypeMeta -> Kind=empty). The keys never matched, so the
skip-path never fired and every item in a terminating namespace paid the full
--terminating-resource-timeout wait (per-resource instead of per-namespace).
Use the passed-in namespace object for Contains so Add/Contains keys match.
Add a regression test that reproduces the production Kind divergence.
Signed-off-by: Shashank1306s <shashasingh@microsoft.com>
Co-authored-by: Shashank1306s <shashasingh@microsoft.com>
Co-authored-by: Priyansh Choudhary <im1706@gmail.com>
(cherry picked from commit de32d93b8e)
* Rename changelog to match backport PR number 10163
hack/changelog-check.sh requires changelogs/unreleased/<current PR number>-*, so the backport needs the backport PR's number rather than the original PR's (#9987).
Signed-off-by: Shashank1306s <shashasingh@microsoft.com>
* Pin e2e third-party clones to reviewed commits
Pin bitnami/containers and distributed-data-generator to fixed SHAs instead of building default-branch HEAD, and add a minimal permissions block.
Signed-off-by: chlins <chlins.zhang@gmail.com>
(cherry picked from commit 02fe822860)
* bump the setup kind action
update kind setup action to helm/kind-action@v1 and use
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true to suppress warning.
Also set cluster_name: "kind" (helm/kind-action defaults to
"chart-testing"), matching the follow-up made on main.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
(cherry picked from commit 7627223d0f)
---------
Signed-off-by: Shashank1306s <shashasingh@microsoft.com>
Signed-off-by: chlins <chlins.zhang@gmail.com>
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Co-authored-by: Shashank1306s <shashasingh@microsoft.com>
Co-authored-by: Priyansh Choudhary <im1706@gmail.com>
Co-authored-by: chlins <chlins.zhang@gmail.com>
Co-authored-by: Adam Zhang <adam.zhang@broadcom.com>
* Fix managed fields patch for resources using GenerateName
When restoring resources with GenerateName (where name is empty and K8s
assigns the actual name), the managed fields patch was failing with error
"name is required" because it was using obj.GetName() which returns empty
for GenerateName resources.
The fix uses createdObj.GetName() instead, which contains the actual name
assigned by Kubernetes after resource creation.
This affects any resource using GenerateName for restore, including:
- PersistentVolumeClaims restored by kubevirt-velero-plugin
- Secrets and ConfigMaps created with generateName
- Any custom resources using generateName
Changes:
- Line 1707: Use createdObj.GetName() instead of obj.GetName() in Patch call
- Lines 1702, 1709, 1713, 1716: Use createdObj in error/info messages for accuracy
This is a backwards-compatible fix since:
- For resources WITHOUT generateName: obj.GetName() == createdObj.GetName()
- For resources WITH generateName: createdObj.GetName() has the actual name
The managed fields patch was already correctly using createdObj (lines 1698-1700),
only the Patch() call was incorrectly using obj.
Fixes restore status showing FinalizingPartiallyFailed with "name is required"
error when restoring resources with GenerateName.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
(cherry picked from commit 898fa13ed7)
* Add changelog file
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
---------
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Update test expectations to include createdName field for resources
with action 'created'. Also ensure namespaces track their created
names when created via EnsureNamespaceExistsAndIsReady.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
(cherry picked from commit c2840f1c74)
When restoring resources with GenerateName, Kubernetes assigns the actual name
after creation, but Velero only tracked the original name from the backup in
itemKey. This caused volume information collection to fail when trying to fetch
PVCs using the original name instead of the actual created name.
Example:
- Original PVC name from backup: "test-vm-disk-1"
- Actual created PVC name: "test-vm-backup-2025-10-27-test-vm-disk-1-mdjkd"
- Volume info tried to fetch: "test-vm-disk-1" → Failed with "not found"
This affects any plugin or workflow using GenerateName during restore:
- kubevirt-velero-plugin (VMFR use case with PVC collision avoidance)
- Custom restore item actions using generateName
- Secrets/ConfigMaps restored with generateName
Changes:
1. Add createdName field to restoredItemStatus struct (pkg/restore/request.go)
2. Capture actual name from createdObj.GetName() (pkg/restore/restore.go:1520)
3. Use createdName in RestoredResourceList() when available (pkg/restore/request.go:93-95)
This fix is backwards compatible:
- createdName defaults to empty string
- When empty, falls back to itemKey.name (original behavior)
- Only populated for GenerateName resources where needed
Fixes volume information collection errors like:
"Failed to get PVC" error="persistentvolumeclaims \"<original-name>\" not found"
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
(cherry picked from commit 07f30d06b9)
Xun Jiang/Bruce JiangandGitHub
lyndon-liandGitHub
Wenkai Yin(尹文开)andGitHub
Lyndon-Li
Shubham PampattiwarandGitHub
Scott SeagoandGitHub
Daniel JiangandGitHub
0xLeo258andLyndon-Li