* Scope schedule and repo CLI list calls to the Velero namespace
velero schedule get, velero schedule describe, velero schedule
pause/unpause and velero repo get built a ctrlclient.ListOptions with a
LabelSelector but no Namespace, so the list ran across every namespace in
the cluster. Their single-name paths in the same functions already scope
to f.Namespace(), and every sibling command (backup get, restore get,
backup describe, restore describe, snapshot-location get, schedule
delete) passes Namespace too, so the omission was an oversight rather
than intent.
The read commands print another installation's Schedules and
BackupRepositories. runPause is worse: velero schedule pause --all and
velero schedule unpause --all fetch Schedules from every namespace and
then write Spec.Paused on each, so pausing one installation's schedules
pauses every other installation's schedules as well.
Add Namespace: f.Namespace() to the four List calls:
pkg/cmd/cli/schedule/get.go:61
pkg/cmd/cli/schedule/describe.go:59
pkg/cmd/cli/schedule/pause.go:114
pkg/cmd/cli/repo/get.go:61
Neither pkg/cmd/cli/schedule nor pkg/cmd/cli/repo had any tests, so the
regression tests are new files. Each seeds a fake client with one object
in the Velero namespace and one in another-velero, and asserts the second
is neither listed, described, nor paused.
Signed-off-by: Max Freedom Pollard <272618364+MaxFreedomPollard@users.noreply.github.com>
* Add changelog for PR 10482
Signed-off-by: Max Freedom Pollard <272618364+MaxFreedomPollard@users.noreply.github.com>
---------
Signed-off-by: Max Freedom Pollard <272618364+MaxFreedomPollard@users.noreply.github.com>
formatUserPriorities stripped only spaces, so an enableapigroupversions
ConfigMap written with CRLF line endings (common for files edited on
Windows) kept a trailing carriage return in each version string, e.g.
"v2beta1\r". versionsContain compares versions with equality, so the
user priority never matched and was silently ignored. Trim the trailing
carriage return so stored versions match again.
Signed-off-by: HeonJe LEE <lhjnano@gmail.com>
* Fix datamover backup arg mismatch for CSI CBT service account name
The exposer built the pod command with --csi-snapshot-metadata-service-sa,
but the datamover backup command only registered --cbt-sa-name. cobra
rejects unknown flags, so the data mover pod exited immediately whenever
a dedicated CBT service account was configured -- and the reverse also
held: since the flags never matched, the SA name never actually reached
the pod, so any code path depending on it stayed unreachable.
Not limited to the block data mover: this line sits outside the
DataMoverTypeVeleroBlock gate and the cbtInfo != nil gate, so it fires
for any CSI snapshot data-movement backup.
Fix: emit --cbt-sa-name (already consumed by the backup command), naming
it consistently with the other CBT flags on the same line (--change-id,
--volume-id, --snapshot-id).
Add a regression test asserting the emitted flag string parses cleanly
against NewBackupCommand's own flag set, so the two sides can't drift
apart again without a test failure.
* Add changelog for #10318
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* Add MustIncludeAdditionalItemPVCs structure in backup. It's used to track PVCs returned by BIA with mustIncluded annotaion and PVC is excluded from backup by global filter.
* Modfiy the volumeHelper interface to add a parameter function for ShouldPerformFSBackup.
* Modify to support fine-grained backup filters.
* Modify according to comments. Use a read-only interface to replace the parameter function.
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
* Add block data mover support for Velero backup/restore describe CLI.
Update output tests to accommodate RestoreType in VolumeInfo
This commit addresses the compilation and assertion errors caused by the introduction of `RestoreType` in `VolumeInfo` and the separation of `SnapshotDataMovementInfo` / `PodVolumeInfo` into their backup and restore counterparts. It fixes references across the test fixtures and the print guard conditions in `restore_describer.go`.
* Modify according to comments
* Add missing JSON tag in the VolumeInfo structures.
* Get uploaderType from the DU and DD's dataMover for the data mover volume info.
* Add IncrementalSize in the data mover volume info.
* Add existingVolumeDataPolicy and restoreType in the restore describe CLI output
* Add more UTs.
* Add some fields value setting that were previously missed.
* Fix the timestamp compare error only found in the GitHub action.
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
An in-place restore onto a different volume than the one backed up is
unsafe: an incremental (CBT) restore computes deltas against a different
volume lineage, and even a full restore would patch and write into an
unrelated volume. Verify the existing PVC is bound and still bound to
the PV recorded at backup time before any side effect, on both the CSI
data mover path (using the backed-up PVC's volume name) and the file
system path (using the PVC-to-PV mapping from the backup volume info).
The PV comparison is skipped for namespace-mapped restores, where the
target PVC is necessarily bound to a different PV (the documented
cross-namespace clone-and-restore workflow).
Signed-off-by: chlins <chlins.zhang@gmail.com>
* Enforce resource filters on cluster-wide items
When backups query all namespaces (wildcard or omitted includes),
the item collector retrieved resources in bulk, bypassing
per-namespace resource filter policies in Stage 1 collection.
This caused resources not listed in the policy to be backed up.
To preserve cluster-wide query performance while enforcing policy
rules, evaluate namespace exclusions, resource kind allowlists,
and label selectors in memory for each collected item.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
* Optimize in-memory resource filter checks
Optimize per-item filter evaluation in the item collector:
- Precalculate GroupResource string once per resource type
- Skip filter policy evaluation when no namespaced policies exist
- Restrict in-memory filtering to cluster-wide queries
- Cache consecutive namespace lookups across collected items
- Lazily extract resource labels only when selectors are present
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
---------
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Check the target PVC is not used by any active pod before any side
effect, on both the CSI data mover path and the file system path.
The in-use semantics align with the pvc-protection controller:
terminal-phase pods don't block, terminating pods block with a wait
hint. On the file system path, pods gated by this restore's
restore-wait init container (identified by the restore UID in its args,
and not yet terminated) are exempted: they must mount the PVC for the
node-agent to restore the data and cannot write to the volume until the
PodVolumeRestores complete. Leftover pods, controller-recreated pods,
and pods gated by a different restore still block.
Signed-off-by: chlins <chlins.zhang@gmail.com>
Add "IncrementalBytes" field to status of DataDownload and PVR to indicate data transferred by the incremental restore
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
* test: Unify duplicate test harness structs in restore and delete tests
Extract the duplicated test harness (fakeRestorer, Harness struct, and
AddResource/AddItems helpers) from restore_test.go and
delete_item_action_handler_test.go into a shared pkg/test.Harness.
Backup tests are intentionally excluded: the shared AddResource strips
metadata.creationTimestamp and status (restore semantics), which would
change what the backup tests tar up and assert on.
Signed-off-by: opbot_xd <awasthikrishna23052005@gmail.com>
* ci: retry
Signed-off-by: opbot_xd <awasthikrishna23052005@gmail.com>
* ci: retry
Signed-off-by: opbot_xd <awasthikrishna23052005@gmail.com>
---------
Signed-off-by: opbot_xd <awasthikrishna23052005@gmail.com>
The CLI now checks backup storage location access mode before submitting
a delete request. Also reject backups with no storage location set and
cache BSL lookups when deleting multiple backups.
Fixes#4203
Signed-off-by: PranjalManhgaye <manhgayepranjal@gmail.com>
Add comprehensive unit tests for pkg/itemblock which previously had
zero test coverage. The new tests cover AddUnstructured and FindItem
methods with 14 test cases across 3 test functions, including preferred
GVR ordering, nil item handling, namespace/name filtering, unparseable
apiVersion handling, and cluster-scoped resource matching.
Fixes#10418
Signed-off-by: opbot_xd <awasthikrishna23052005@gmail.com>
* Report a measured zero incremental instead of erasing it
A CBT incremental with an exactly zero delta -- nothing changed since
the parent -- was reported identically to a backup that moved the whole
device. `velero backup describe --details` printed only
"Moved data Size (bytes): 3221225472" with no incremental line, and
status.incrementalBytes was absent, for a run that transferred nothing.
The best possible CBT outcome displayed as the worst, and was
indistinguishable from a genuine full, a whole-device fallback, or a
backup predating incremental accounting.
The zero was being erased twice. Besides the API status fields,
datapath.BackupResult also carried omitempty, and that struct crosses a
JSON boundary from the data mover pod to the controller (see
micro_service_watcher.go), so the value was destroyed before the
controller could persist it. Every uploader always reports a figure
there, so 0 internally always means "transferred nothing" -- dropping
omitempty is sufficient and correct for that hop.
The API fields move to *int64 rather than just dropping omitempty. The
field shipped in v1.18.0-v1.18.2, so backups exist whose stored volume
info has no incrementalSize at all; with a plain int64 those unmarshal
to 0 and would render "Incremental data Size (bytes): 0", a false claim
of a perfect incremental on a run that never measured one. nil means not
measured, a pointer to 0 means measured zero. Both fields already carry
+optional, so the generated CRD schema is unchanged and no regeneration
is required.
Display gates relax from > 0 to != nil in all three places, including
volumesByPod.Add, whose signature takes *int64 now; the restore describer
passes nil, which is correct since restores measure no incremental.
Verified live: the same zero-delta scenario that reported <none> now
reports 0 and renders "Incremental data Size (bytes): 0", while an older
backup described with the new client still correctly prints no
incremental line at all.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
(cherry picked from commit 6c7aa9d588f6d5eab134d4ce19c92b838f45557c)
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* gofmt: fix import ordering in backup_test.go
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* Regenerate CRDs for IncrementalBytes pointer type
make update-crd was missed in the original commit. Regenerated with
the pinned controller-gen v0.16.5 to avoid unrelated version-annotation
churn across other CRDs.
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* Add changelog for #10309
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* Address review: make IncrementalBytes a pointer to preserve backward compat
Per Lyndon-Li's review on #10309: dropping omitempty on the plain int64
field breaks compatibility with a data mover from release-1.17 or
earlier that predates IncrementalBytes and never writes the key -- the
new controller would unmarshal a zero value ("nothing transferred")
instead of recognizing the field is simply absent ("not measured").
Switch to *int64 with omitempty restored:
- an old mover's omitted key unmarshals to nil ("not measured")
- a current mover's genuine zero still serializes the key, unmarshaling
to a non-nil pointer to 0 ("measured zero")
- nonzero values work exactly as before
- an old controller can still unmarshal a numeric value from a new mover
pkg/controller/data_upload_controller.go and pod_volume_backup_controller.go
assign the wire-struct field directly to their already-*int64,omitempty
CRD status field instead of re-wrapping it with ptr.To, since both are
now the same pointer type.
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* Fix CI: update marshal-fail test assertions for IncrementalBytes pointer
Both backup_micro_service_test.go files hardcoded the %v-formatted
zero-value BackupResult struct in an error-message assertion. Now that
IncrementalBytes is *int64, its zero value prints as <nil> instead of 0.
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
---------
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Issue #3194: Add velero client set-context-as-velero-namespace command
Saves the namespace of the current (or a specified) kubeconfig context
into the Velero client config file, so operational commands default to
it without requiring --namespace on every invocation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: lubronzhan <lubron.zhan@broadcom.com>
* Fix CI: rename changelog to PR number, add unit tests for coverage
- changelogs/unreleased must be named <pr-number>-<username>; rename
from the 0000 placeholder to 10127 to satisfy hack/changelog-check.sh.
- Extract the command's logic into setContextAsVeleroNamespace so it's
testable without triggering os.Exit via cmd.CheckError, and add unit
tests covering: namespace read from context, context with no explicit
namespace, overwriting an existing config value, and invalid
kubeconfig path. Addresses 0% codecov patch coverage on the PR.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: lubronzhan <lubron.zhan@broadcom.com>
* Move set-namespace-from-context under client config
Shubham suggested nesting the new command under `config` for
hierarchy consistency, and renaming it since the original
set-context-as-velero-namespace name was long and ambiguous. Moves
it to `velero client config set-namespace-from-context`, matching
the existing config get/set subcommands and my follow-up naming
suggestion on the review thread.
AI-Tool-Used: Claude Code
AI-Tool-Use-Level: Category 3 (Low)
AI-Code-Category: Category 1 (Production)
Signed-off-by: lubronzhan <lubron.zhan@broadcom.com>
* Replace set-namespace-from-context with namespace-mode=auto
kaovilai noted on #10127 that a one-shot command to snapshot the
kubecontext namespace becomes redundant once a config toggle can
resolve it dynamically, and isn't much simpler than the existing
`config set namespace=...` alternative.
Drop the dedicated set-namespace-from-context subcommand and instead
teach the client Factory to resolve the operational namespace from the
current kubeconfig context on every invocation when
`namespace-mode=auto` is set via the existing generic
`config set` command. Explicit --namespace flags and VELERO_NAMESPACE
still take precedence, so the new mode only changes behavior when
neither is set.
AI-Tool-Used: Claude Code
AI-Tool-Use-Level: Category 2 (Medium)
AI-Code-Category: Category 1 (Production)
Signed-off-by: lubronzhan <lubron.zhan@broadcom.com>
* Address PR review: doc, fallback test, t.Setenv
Resolve feedback from PR #10127 review 4966054980:
- Document how to disable namespace-mode=auto (namespace-mode=)
and note the fallback to the static namespace, in namespace.md.
- Add a factory test covering the fallback to the stored/default
namespace when kubeconfig namespace resolution fails.
- Switch the VELERO_NAMESPACE override test to t.Setenv, wrapped
in a subtest so its cleanup runs before later tests execute.
AI-Tool-Used: Claude Code
AI-Tool-Use-Level: Category 2 (Medium)
AI-Code-Category: Category 2 (Non-Production)
Signed-off-by: lubronzhan <lubron.zhan@broadcom.com>
---------
Signed-off-by: lubronzhan <lubron.zhan@broadcom.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* Fix e2e cache miss on force push by saving artifacts explicitly
actions/cache@v4 writes the cache in a post-job hook that runs after the
job reports completion. The run-e2e-test jobs (needs: build) start as
soon as build completes, before that post-hook save runs, so on a force
push -- where the github.sha-keyed cache has no prior entry -- they
deterministically miss the cache and fail with
'stat velero.tar: no such file or directory'.
Switch the build job's lookups to actions/cache/restore and add explicit
actions/cache/save steps at the end of the job (CLI, image, and MinIO),
so the cache is written before build reports done. The run-e2e-test
reads become actions/cache/restore.
Fixes#9927
Signed-off-by: alliasgher <alliasgher123@gmail.com>
* Add changelog for #9952
Signed-off-by: alliasgher <alliasgher123@gmail.com>
---------
Signed-off-by: alliasgher <alliasgher123@gmail.com>
* Add readWriteOncePod backupPVC config to enable mount-level SELinux labeling
On SELinux-enabled clusters the kubelet recursively relabels every file of
the backupPVC at mount time, which can take hours on volumes with a high
file count. Kubernetes avoids this when the volume is ReadWriteOncePod and
the CSI driver advertises SELinux mount support, by mounting with
-o context= instead.
Add an opt-in per-storage-class 'readWriteOncePod' backupPVC config option
that creates the backupPVC with the ReadWriteOncePod access mode and sets
the backup pod's SecurityContext.SELinuxChangePolicy to MountOption. It is
mutually exclusive with 'readOnly', which takes precedence.
Fixes#9873
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
* Add changelog file
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
* Do not set SELinuxChangePolicy for the backup pod
Live testing on OCP 4.22 (k8s 1.35) showed that setting
SecurityContext.SELinuxChangePolicy to MountOption makes backup pod
creation fail outright when the SELinuxMount feature gate is disabled,
which is the default on current clusters:
Pod is invalid: spec.securityContext.seLinuxChangePolicy:
Unsupported value: "MountOption": supported values: "Recursive"
The field is also unnecessary. For ReadWriteOncePod volumes the kubelet
already performs mount-level SELinux labeling via the
SELinuxMountReadWriteOncePod feature gate, which has been on by default
since k8s 1.28. Setting the backupPVC access mode to ReadWriteOncePod is
sufficient on its own, and is portable to clusters where the broader
SELinuxMount gate is still off.
Verified on-cluster that the backupPVC is mounted with
context="system_u:object_r:container_file_t:s0:c22,c28" instead of the
recursive seclabel mount used without the flag.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
---------
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
lyndon-liandGitHub
Max Freedom PollardandGitHub
HeonJe LeeandGitHub
Tiger KaovilaiandGitHub
Lyndon-Li
Xun Jiang/Bruce JiangandGitHub
Chlins ZhangandGitHub
KrishhnaTandGitHub
Adam ZhangandGitHub
Wenkai Yin(尹文开)andGitHub
opbot_xd
R4mboandGitHub
Krishna AwasthiandGitHub
PranjalandGitHub
Pierluigi Lenoci
Xun Jiang
Tiger Kaovilai
Ali AsgharandGitHub
Shubham PampattiwarandGitHub