Guard the cleanupStubVGSC() call in restore finalization with a check
for VolumeGroupSnapshotHandle in volumeInfo. This avoids a spurious
warning on clusters where the v1beta2 VolumeGroupSnapshotContent CRD
is not installed, since the List call would fail even though no stubs
exist to clean up.
Fixes#9882
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
fix fallbacks in backup filter policies,
- refactor the code to start with global policies, and apply
override if exists, and document the behaviour inline according
to the design
- Ensure that unlisted cluster-scoped kinds properly fall back
to global label selectors
- unlisted namespace-scoped kinds are explicitly skipped when
evaluating policy label selectors
add test coverage for GetNamespaceFilter glob matching and ordering
Added a unit test to verify that GetNamespaceFilter correctly matches
compiled glob patterns against namespace strings, and properly honors
first-match semantics when a namespace matches multiple patterns.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
implement backup logic to support backups with
NamespacedFilterPolicies and ClusterScopedFilterPolicy
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Legacy filters should not be co-exist with new filters defined in
resource policies,
- ClusterScopedFilterPolicy
- NamespacedFilterPolicy
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
add test cases to cover positive scenario
add test case to cover the scenario that backup can
complete successfully with namespacedFilterPolicies
and clusterScopedFilterPolicy.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Per review feedback on #9791, the previous revision still let a
DataUpload with an empty velero.io/backup-name label fall through to
genConfigmap, creating a ConfigMap that deleteMovedSnapshots can never
match back to a snapshot. The CM is useless and only adds etcd churn.
Treat the missing-label case the same way as the foreign-owner case:
warn and skip the ConfigMap creation. Use a distinct warn message so
operators can tell the two misconfiguration classes apart in logs
(missing-label vs. owner mismatch from a captured velero namespace).
Test for the missing-label case is updated to assert no ConfigMap is
created and a warn is emitted. The warn assertion is generalized to
match the per-case message substring instead of a fixed string.
Signed-off-by: Christian Schlichtherle <christian@schlichtherle.de>
- added ClusterScopedFilterPolicy/NamespacedFilterPolicy
- added run time data structure, ResolvedResourceFilter and ResolvedNamespaceFilter
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Velero does not support self-protection: the velero namespace must
never be captured in a backup tarball. When it is, the tarball can
contain DataUpload CRs belonging to other backups, and the previous
revision of this change silently swallowed that case in the
DataUploadDeleteAction.
Per maintainer feedback, the action should make the misconfiguration
detectable rather than silent. Emit a warn-level log naming the
DataUpload, its owning backup-name label, and the executing backup,
and call out that the velero namespace should be excluded from
schedules. Continue to skip the snapshot-info ConfigMap creation so
that a mislabeled CM does not mask the real owning backup's snapshot
on deletion.
The test for the foreign-backup case now also asserts the warn is
emitted via a logrus test hook.
Signed-off-by: Christian Schlichtherle <cs@bsure-analytics.de>
When a backup tarball incidentally contains DataUpload CRs that belong to
a different backup (common when a schedule includes the velero namespace
where DataUploads live), DataUploadDeleteAction.Execute used to create a
"<du-name>-info" ConfigMap labeled with the *executing* backup's name
instead of the DataUpload's true owning backup. The ConfigMap is
created with Create-only semantics, so the wrong label is never
corrected.
deleteMovedSnapshots in the backup-deletion controller looks up these
ConfigMaps by velero.io/backup-name to discover which Kopia snapshots
to delete. With the wrong label, the real owning backup's expiry pass
finds no ConfigMaps for its DataUploads and silently leaves their Kopia
snapshots in object storage, leaking data over time.
Fix: in DataUploadDeleteAction.Execute, compare the DataUpload's
velero.io/backup-name label against input.Backup.Name (using
label.GetValidName to handle DNS-1035 truncation for long backup names).
If the label is present and differs, skip the DataUpload entirely; this
prevents the over-eager creation of misnamed ConfigMaps without changing
behavior for DataUploads that legitimately belong to the executing
backup, or for legacy DataUploads with no backup-name label.
Refs: #9472
Signed-off-by: Christian Schlichtherle <cs@bsure-analytics.de>
Xun Jiang
lyndon-li
Adam Zhang
Lyndon-Li
Shubham Pampattiwar
Subhramit Basu
Wenkai Yin(尹文开)
Christian Schlichtherle
Christian Schlichtherle