Add validation rules for NamespacedFilterPolicies to fail fast
for invalid NamespacedFilterPolicies.
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>
The netlify error analysis:
The problem is that base = "site/" makes the build run from the site subdirectory, and publish = "site/public" is resolved relative to the repo root as site/site/public — but Hugo outputs to site/public. Since the base is already site/, the publish path should just be public (relative to the base directory).
Signed-off-by: Daniel Jiang <daniel.jiang@broadcom.com>
- rename FineGrainedGlobalFilterPolicy to ClusterScopedFilterPolicy
- add warning message in several places to help debug
- cleanup conflicting validations
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>
enhance backup filter with resource policies, extend resource
policies with fine-grained control for backup resources, both
cluster scoped resources and namespace scoped resources, with
labels, names include/exclude support with glob patterns.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Adam Zhang
lyndon-liandGitHub
Lyndon-Li
Daniel JiangandGitHub
Tiger KaovilaiandGitHub
Christian SchlichtherleandGitHub
Xun Jiang
Christian Schlichtherle