fix: match backup targets to restore PVC labels

[weicao]

Problem

Backup dataSource PVC restore can be incorrectly classified as provision-only when the Backup target pod selector contains labels that exist only on Pods.

In the Valkey rerun, restore intent projection was present: the restore Cluster had spec.restore.source and restore PVCs had Backup dataSource/dataSourceRef. VolumePopulator still emitted provision-only events and skipped the data restore branch.

Fixes #10352

What changed

• Changed VolumePopulator target-to-PVC matching to evaluate only selector labels that are present on PVCs.
• Kept component-scoped target matching intact, so non-target components such as sentinel PVCs still stay provision-only.
• Added a focused unit test covering a Backup target selector with both component label and pod-only role label.

Verification

Passed:

go test ./controllers/dataprotection -run 'TestDecidePVCRestore(IgnoresPodOnlyTargetLabelsForPVCMatch|KeepsSingleBackupTargetScopedToMatchingComponent|UsesTargetVolumes|TreatsNilTargetVolumesAsProvisionOnly)' -count=1

Full package (previously blocked locally by missing etcd, now verified with envtest assets):

go test ./controllers/dataprotection -count=1   # ok, 46s

Runtime boundary

Draft PR only. Runtime acceptance is not complete yet. Valkey needs a patched controller rerun and should capture Backup target, PVC dataSourceRef, VolumePopulator events, PVC/PV status, and restore readback.

This is not Valkey release PASS and not a Valkey product FAIL.

[apecloud-bot]

Auto Cherry-pick Instructions

Usage:
  - /nopick: Not auto cherry-pick when PR merged.
  - /pick: release-x.x [release-x.x]: Auto cherry-pick to the specified branch when PR merged.

Example:
  - /nopick
  - /pick release-1.1

CLA Recheck Instructions

Usage:
  - /recheck-cla: Trigger a re-check of CLA status for this pull request.
Example:
  - /recheck-cla

[leon-ape]

This now ignores every selector key that is absent from the PVC. That is correct for Pod-only labels like role, but it also makes PVC-scoped labels optional. For example, a scoped target with component=valkey can still match a PVC that is missing the component label as long as another generic label such as managed-by matches, and the single-target path will restore data from that target.

Please distinguish PVC-scoped labels from Pod-only labels: missing component/sharding labels should be treated as a non-match, while role-like Pod-only labels can be ignored. Please also add a regression test where the target selector has component + role but the PVC is missing the component label and must not restore data.

[weicao]

Addressed in c3a5b29: backupTargetSelectorKeyScopesPVC distinguishes PVC-scoped keys (component, sharding, volume-claim-template name) from Pod-only keys — a selector key that is absent from the PVC is now a non-match when it is PVC-scoped and ignored otherwise. Regression test TestDecidePVCRestoreRequiresPVCScopedTargetLabels covers the component-label-missing PVC staying provision-only. Full controllers/dataprotection package also verified with envtest assets (previously blocked locally).

[weicao]

Addressed the PVC-scoped selector concern in commit c3a5b29.\n\nWhat changed:\n- Missing PVC-scoped backup target labels now make the target a non-match.\n- PVC-scoped keys currently include component, sharding, and volume claim template labels.\n- Pod-only labels such as role can still be ignored when absent from the PVC, preserving the Valkey restore case.\n- Added a regression test where the target selector has component + role but the PVC is missing the component label; it must stay provision-only.\n\nVerification:\n- git diff --check\n- go test ./controllers/dataprotection -run 'TestDecidePVCRestore(IgnoresPodOnlyTargetLabelsForPVCMatch|RequiresPVCScopedTargetLabels|KeepsSingleBackupTargetScopedToMatchingComponent|UsesTargetVolumes|TreatsNilTargetVolumesAsProvisionOnly)' -count=1\n\nBoundary: PR remains draft until the patched image passes the Valkey restore runtime acceptance rerun.

[codecov]

Codecov Report

❌ Patch coverage is 63.63636% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 53.11%. Comparing base (00feefe) to head (c3a5b29).
⚠️ Report is 14 commits behind head on main.

Files with missing lines	Patch %	Lines
...llers/dataprotection/volumepopulator_controller.go	63.63%	12 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10354      +/-   ##
==========================================
- Coverage   53.14%   53.11%   -0.03%     
==========================================
  Files         532      532              
  Lines       63135    63140       +5     
==========================================
- Hits        33551    33536      -15     
- Misses      26158    26168      +10     
- Partials     3426     3436      +10     

Flag	Coverage Δ
unittests	53.11% <63.63%> (-0.03%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[weicao]

Self-review against current main: the motivating scenario is already covered by #10445 (merged 06-24, isPodOnlyLabel denylist for app.kubernetes.io/instance and kubeblocks.io/role). Both regression tests from this PR pass unchanged on current main — the only net delta left is 'skip any unknown pod-only label' (allowlist inversion), which no test here covers and no real backup shape has been shown to need. The branch is also a month behind main with textual conflicts in both files, and the missing-key handling for MatchExpressions inverts K8s LabelSelector semantics (NotIn/DoesNotExist on a missing key should match). Recommending close; if a real backup producer emits pod-only selector labels beyond role, a narrow follow-up on top of main's isPodOnlyLabel with a RED-on-main test would be the right shape.

[weicao]

Closing per the analysis above: the motivating scenario is covered by merged #10445 (both regression tests here pass unchanged on current main), and the remaining delta has no demonstrated producer. A narrow follow-up on top of main's isPodOnlyLabel with a RED-on-main test is the right shape if a real multi-label backup form appears.