Make resources to be excluded/included configurable

[xing-yang]

Describe the problem/challenge you have

We have a way to filter resources by using -include-resources or -exclude-resources, but it is cumbersome and error prone if there is a large number of resources to be included/excluded.

Describe the solution you'd like

The request is to allow the user to put resources to be included/excluded in a configmap. This way it is easier to manage.

Anything else you would like to add:

Environment:

• Velero version (use velero version): 1.15.1 and earlier
• 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]

Just to clarify the request -- this would be to provide all of the same fields as we currently have directly in backup.spec but accepted via a ConfigMap input, presumably so that the same list can be shared across backups?

One way to implement this would be to do it in the Velero client with no CRD changes to backups.velero.io -- velero backup create --include-exclude-configmap foo would parse the configmap and create the velero Backup CR with the spec fields populated exactly as it does now with the explicit include/exclude args. The CLI could either prohibit the configmap from being used along with the explicit include/exclude args, or it could treat explicit args as overrides to the configmap.

The other approach would be to add a new spec field for this configmap and pull the configmap contents at backup processing time. For backups created directly, the behavior would be roughly similar. For backup schedules, though, there would be an important difference. The client approach would set the includes/excludes at schedule creation time. The "add configmap to CRD" approach would set them at backup processing time. So for a daily schedule, modifying the configmap after schedule creation would affect future scheduled backups with this approach. With the client approach, modifying the configmap will only affect schedules created after the change.

[xing-yang]

Just to clarify the request -- this would be to provide all of the same fields as we currently have directly in backup.spec but accepted via a ConfigMap input, presumably so that the same list can be shared across backups?

Yes.