Design: namespace selection by label in resource policy

[kaovilai]

Summary

• Adds design document for extending includeExcludePolicy in ResourcePolicy configmap with includedNamespacesByLabel and excludedNamespacesByLabel fields
• Users can dynamically include/exclude namespaces by Kubernetes label selectors without modifying BackupSpec or schedule specs
• Covers precedence rules, OR/AND selector semantics, observability via backup status, and rejected alternatives

Test plan

• Design review by maintainers
• Implementation to follow after design approval

Fixes #7492

Note

Responses generated with Claude

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Lyndon-Li]

@kaovilai
FYI of this issue #9448, @adam-jian-zhang is trying to making a new type of resource selection solution that supports nested and fine grained selecting of resources (for both namespaced and cluster scope resources), this solution will also be implemented in ResourcePolicy because: 1. the interfaces are complex and the existing filters cannot handle it; 2. as we discussed previously, it is the right direction to have the sophisticated policies into ResourcePolicy.

I think there are some overlaps for these two designs, let's discuss how we are going to handle them. cc @adam-jian-zhang @reasonerjt

[kaovilai]

Oh hi adam.

[adam-jian-zhang]

hi tiger,
Yes, I am also working on the backup filters improvement, here is my design:
https://github.com/adam-jian-zhang/velero/blob/backup-filter-design/design/backup-filter-enhancement/fine-grained-backup-filters-design.md
I have not raised PR yet, we are doing internal review first to make the design solid before proposing PR, we have been doing this for two rounds and are quite close to proposing PR.
I think the design can also cover the use cases presented in this PR, and many others.
Let's discuss how to move forward with this.

[kaovilai]

Thank you Adam. From community meeting, it is my understanding that your design will not cover "namespace selection by label" requirement documented in #7492.

The requirement states that user can choose namespaces to backup similar to velero backup create --included-namespaces by using labelSelector on namespaces instead of specifying namespace names into backup spec.

It was suggested to use resource policy for that, hence I retitled the issue in 7492. I will keep my design 9772 here open/draft and try to make it compatible with your design.

[adam-jian-zhang]

@kaovilai ,
I look it more carefully, I think I only need a small adjustment to incorporate the namespace with labels use cases in my design. Basic ideas is adding labels selector in the namespacedFilterPolicies to express the namespace selection requirement, something like:

version: v1
namespacedFilterPolicies:
  - namespaceLabelSelector: # New to address the use cases for this design
      environment: production
    excludedNamespaceLabelSelector:  # New to address the use cases for this design
      skip-selective-backup: "true"
    resourceFilters:
      - kinds: [ConfigMap, Secret, Deployment]
        labelSelector:
          app: my-app

What do you think?
I will update my design later to include this.

[kaovilai]

That works! Thank you

[adam-jian-zhang]

@kaovilai,
I have tried to incorporate the namespace label selector use cases into fine grained resource filter design, here is the draft design,
https://github.com/adam-jian-zhang/velero/blob/backup-filter-design-alternative/design/backup-filter-enhancement/fine-grained-backup-filters-design.md#use-labels-to-assign-namespaces-to-different-backup-schedules

But during the review we all thought it was too complicated.
And I had to bend several validation rules and inverse the empty resourceFilters meaning to accommodate that.
I think it's better to keep those two designs separate, since it addresses different requirements.
Namespace label filters address global namespace selection, and fine-grained resource filters address per namespace fine tuning after the selection. It is totally possible to deliver them separately.
cc @Lyndon-Li @reasonerjt