Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: Extend Volume Policy criteria to include label selector #8256

Open
shubham-pampattiwar opened this issue Sep 30, 2024 · 1 comment
Open

Comments

@shubham-pampattiwar
Copy link
Collaborator

Describe the problem/challenge you have

Currently, Volume Policies in Velero support basic criteria for managing volumes during backup operations. However, the lack of a label selector feature limits flexibility in applying policies to specific sets of volumes. By extending the Volume Policy criteria to include label selectors, users can more effectively manage their storage resources based on custom labeling strategies, enhancing automation and operational efficiency.

Describe the solution you'd like

Extend the Volume Policy criteria definition to support label selectors.

Anything else you would like to add:

Environment:

  • Velero version (use velero version):
  • Kubernetes version (use kubectl version):
  • Kubernetes installer & version:
  • Cloud provider or hardware configuration:
  • 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 "The project would be better with this feature added"
  • 👎 for "This feature will not enhance the project in a meaningful way"
@sseago
Copy link
Collaborator

sseago commented Sep 30, 2024

We've seen several customer requests for this -- they tend to be things like "I don't want to back up the content of my database volumes because we have hooks to do a db dump to a separate volume and we want to back up that volume but not the live DB volume" -- this isn't easily accomplished with the current selection criteria around capacity, volume type, etc. since there's a good chance the volume wanted to back up and the one not wanted have the same type, provisioner, size, etc. But if they can label the volumes "do-not-backup" or whatever and then create a volume policy with a label selector matching that label with the skip action, they could accomplish this easily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants