-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Description
What steps did you take and what happened:
I am using a custom helm chart with velero
chart as a dependency:
# Chart.yaml
apiVersion: v2
name: <name>
description: <desc>
type: application
version: 1.0.0
dependencies:
- name: velero
version: 10.0.5
repository: https://vmware-tanzu.github.io/helm-charts
condition: velero.enabled
This implies a deployment with velero
has a name like <chart-name>-velero
.
Making a Backup
and then trying to create a Restore
object leads to the following error in the controller:
time="2025-06-13T06:45:17Z" level=error msg="Velero restore error: rpc error: code = Unknown desc = deployments.apps \"velero\" not found"
Without wrapped errors, it is virtually impossible to determine the exact location of the error.
After wrapping errors, it was clear to me that the problem was introduced in #8574 with the hardcoded name of the velero
Deployment
:
# example with wrapped errors
time="2025-06-16T10:45:54Z" level=error msg="resolving action name velero.io/pod" logSource="pkg/plugin/framework/action_resolver.go:243"
time="2025-06-16T10:45:54Z" level=error msg="resolving action name velero.io/pod-volume-restore" logSource="pkg/plugin/framework/action_resolver.go:243"
time="2025-06-16T10:45:54Z" level=error msg="failed to resolve actions: failed to resolve actions: failed to resolve action velero.io/pod-volume-restore: failed to applies to: rpc error: code = Unknown desc = deployments.apps \"velero\" not found" logSource="pkg/restore/restore.go:250" restore=kcm-system/whatever
time="2025-06-16T10:45:54Z" level=error msg="Velero restore error: failed to resolve actions: failed to resolve action velero.io/pod-volume-restore: failed to applies to: rpc error: code = Unknown desc = deployments.apps \"velero\" not found" logSource="pkg/controller/restore_controller.go:599" restore=kcm-system/whatever
A quick search for the velero.io/pod-volume-restore
and traversing through the code led to the aforementioned PR with the hardcoded name.
What did you expect to happen:
Restore actions proceed even when velero
Deployment
's name does not exactly equal "velero"
without customizing the plugin's config
I would like to see a label selector for component=velero
rather than the hardcoded name.
If the issue is legit and the suggested change to a label selector is okay-ish, I could submit a PR right away.
The following information will help us better understand what's going on:
If you are using velero v1.7.0+:
Please use velero debug --backup <backupname> --restore <restorename>
to generate the support bundle, and attach to this issue, more options please refer to velero debug --help
If you are using earlier versions:
Please provide the output of the following commands (Pasting long output into a GitHub gist or other pastebin is fine.)
kubectl logs deployment/velero -n velero
velero backup describe <backupname>
orkubectl get backup/<backupname> -n velero -o yaml
velero backup logs <backupname>
velero restore describe <restorename>
orkubectl get restore/<restorename> -n velero -o yaml
velero restore logs <restorename>
bundle-2025-06-16-13-13-06.tar.gz
Anything else you would like to add:
Environment:
- Velero version (use
velero version
):Client: Version: v1.16.1 Git commit: - Server: Version: v1.16.1
- Velero features (use
velero client config get features
): defaults - Kubernetes version (use
kubectl version
):Client Version: v1.33.1 Kustomize Version: v5.6.0 Server Version: v1.33.1
- Kubernetes installer & version:
kind v0.29.0
- Cloud provider or hardware configuration: none
- OS (e.g. from
/etc/os-release
):
Vote on this issue!
This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.
- 👍 for "I would like to see this bug fixed as soon as possible"
- 👎 for "There are more important bugs to focus on right now"