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>
* Update CRDs and CLI to support in-place restore (#10038)
Update CRDs(Restore, DataDownload, PodVolumeRestore) and restore create CLI to support in-place restore
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
* Update Kopia(filesystem) uploader to support incremental and deleteExtraFile during restore (#10066)
Update Kopia(filesystem) uploader to support incremental and deleteExtraFile during restore
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
* Update Restore Exposer and PVC CSI to support in-place restore (#10104)
1. Update Restore Exposer to support exposing with existing PV for in-place restore
2. Update PVC CSI RIA to continue the restore process for in-place restore
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
* Update Block uploader to support increase restore (#10244)
Update Block uploader to support increase restore
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
* Update Exposer to recreate the target PV if the volume mode is different with the restore PVC (#10257)
Update Exposer to recreate the target PV if the volume mode is different with t
he restore PVC
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
* Preserve PVC selected-node annotation via carrier annotation for in-place restore
For in-place volume data restore, the existing PVC is deleted and
recreated. For StorageClasses with the WaitForFirstConsumer volume
binding mode, losing the volume.kubernetes.io/selected-node annotation
could let the scheduler place the recreated workload Pod in a different
zone than the original PV, leaving it stuck in ContainerCreating.
Instead of relying on RestoreItemAction execution order (the generic
PVC RIA unconditionally strips the selected-node annotation), the PVC
CSI RIA now captures the annotation from the existing PVC right before
deleting it and carries it on the target PVC via the Velero-internal
restore.velero.io/inplace-restore-selected-node annotation. The restore
engine translates the carrier back to the Kubernetes annotation after
all RestoreItemActions have run and always strips the carrier so it
never lands on the cluster.
This makes the behavior independent of RIA ordering: the Kubernetes
annotation is stripped by default on every path (including when the
target PVC does not exist and Velero falls back to provisioning a new
PVC), and preservation only happens when the CSI RIA explicitly
captured a value from the existing PVC.
Signed-off-by: chlins <chlins.zhang@gmail.com>
* Update the control path to make the in-place incremental restore with block data mover work E2E (#10410)
Update the control path to make the in-place incremental restore with block data mover work E2E
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
---------
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
Signed-off-by: chlins <chlins.zhang@gmail.com>
Co-authored-by: chlins <chlins.zhang@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>
Backups stuck in New state have no Status.Expiration yet. The CLI
was estimating expiration from CreationTimestamp + TTL, which made
long-queued backups appear already expired.
Fixes#3555
Signed-off-by: PranjalManhgaye <manhgayepranjal@gmail.com>
* Skip signing a download URL when no artifacts can exist yet
Reported in #10232: a DownloadRequest for a backup that never ran still
reaches Processed with a signed URL, and fetching it returns 404.
The controller already has the backup, and the restore for restore
targets, in hand before it signs, so checking the phase costs no extra
call to the object store.
The check is deliberately narrow. It refuses only the pre-execution
phases, where nothing has been written for any target kind: New, Queued,
ReadyToStart and FailedValidation for backups, New and FailedValidation
for restores. InProgress onwards may hold a partial log or other
artifacts, and Deleting may still hold all of them, so those keep the
behaviour callers have today.
That matters because velero backup download has no client side phase
check of its own, unlike backup logs and restore logs. Reusing the
allowlist from pkg/cmd/cli/backup/logs.go would have changed what
backup download can fetch; this does not.
A backup with an empty phase is left alone as well, since that state is
transient and the caller can retry.
Refs #10232
Signed-off-by: saral <ilovegojo2580@gmail.com>
* Derive the phase coverage test from the generated CRDs
The previous test built a slice of phases by hand and asserted its own
length, so it passed no matter what the API did. Adding a fourteenth
backup phase would not have failed it.
This reads the status.phase enum out of the generated CRDs, via the
exported v1crds.CRDs that pkg/install already uses. The enum comes from
the same kubebuilder markers as the Go constants, so a phase added to
the API fails here until it is classified.
Verified by removing Deleting from the expectations, which now fails with
'BackupPhase "Deleting" is served by the CRD but not classified'.
Signed-off-by: saral <ilovegojo2580@gmail.com>
* Use US spelling in comments to satisfy the misspell linter
golangci-lint runs misspell, which flags behaviour as a misspelling of
behavior. Comments only, no functional change.
Signed-off-by: saral <ilovegojo2580@gmail.com>
* Set a Failed phase with a reason when the guard refuses to sign
The guard added in the previous commit left the request at New with no URL, so
the CLI polled until its own timeout and then reported that the backup storage
location may be unavailable. The BSL is fine; the backup never ran.
DownloadRequestPhase gains Failed and DownloadRequestStatus gains Message. The
controller sets both where it refuses, and the CLI stops as soon as it sees the
phase and surfaces the message instead of its generic timeout error.
Adding an enum value is additive, per the direction on the PR discussion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: saral <ilovegojo2580@gmail.com>
---------
Signed-off-by: saral <ilovegojo2580@gmail.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* cap the unzip of metadata download to avoid oom kill
Signed-off-by: Lyndon-Li <lyonghui@vmware.com>
* detect when EOF is retuend because of cap
Signed-off-by: Lyndon-Li <lyonghui@vmware.com>
---------
Signed-off-by: Lyndon-Li <lyonghui@vmware.com>
velero backup get prints <nil> in CREATED for a backup that never
started, and velero restore get prints it in both STARTED and COMPLETED.
The timestamps are *metav1.Time and are appended to the row unformatted,
so a nil pointer reaches the user as Go's nil literal.
This is reachable in ordinary use. A backup that fails validation never
starts, so StartTimestamp is never set, and a restore that fails
validation gets neither timestamp.
formatTimestamp returns n/a for an unset value, matching
humanReadableTimeFromNow, which already handles a zero expiration in the
same row. A set timestamp is unchanged.
Adds tests for both printers, which had no row-level coverage.
Signed-off-by: saral <ilovegojo2580@gmail.com>
pkg/cmd/cli/restore/logs.go was the last command in the CLI still calling
cmd.Exit, which calls os.Exit directly. Two of its own tests were skipped
because of it, and said so:
t.Skip("Cannot test restore not complete case due to cmd.Exit() call")
This gives restore logs the LogsOptions shape that backup logs already
uses: Complete, BindFlags and Run returning an error, with the cobra
command passing that to cmd.CheckError. Both skipped tests now run and
assert on the returned errors.
Exit status is unchanged; cmd.CheckError also exits 1. The two refusal
messages now carry the standard "An error occurred:" prefix and match
the wording backup logs uses.
Signed-off-by: saral <ilovegojo2580@gmail.com>
Register cobra completion callbacks for all commands that accept
existing Velero resource names. A centralized completeNames helper
uses apimachinery's meta.ExtractList/Accessor to list resources with
a 3-second timeout, filter by prefix, and deduplicate already-typed
arguments. Wires ValidArgsFunction on 20 commands and
RegisterFlagCompletionFunc on 9 flags across backup, restore,
schedule, backuplocation, snapshotlocation, repo, and debug.
Closes#9782
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Joseph <jvaikath@redhat.com>
Add the flag to the existing TestCreateCommand test to verify flag
binding and option parsing.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
- Add Default Resource Modifiers section to restore-resource-modifiers.md
- Add --default-resource-modifier-configmap to customize-installation.md
- Add examples/default-resource-modifier-cni.yaml with CNI annotation
stripping rules for OVN-K and Multus
- Update restore describer to show SkipDefaultResourceModifier when set
- Log warning when ResourceModifier Kind is not ConfigMap instead of
silently doing nothing
- Add deployment_test.go coverage for the new server flag
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Add --default-resource-modifier-configmap to the install CLI and
deployment builder so administrators can configure it during velero
install. Wire through VeleroOptions and podTemplateConfig following
the existing --backup-repository-configmap pattern.
Add SkipDefaultResourceModifier builder method to RestoreBuilder.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
When set, the server-configured default resource modifier is skipped
for this restore. Only sets the *bool field when the flag is true,
leaving it nil otherwise.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Thread DefaultResourceModifierConfigMap from server config through to
restoreReconciler. Refactor validateAndComplete to use a shared
loadResourceModifierConfigMap helper that handles both default and
per-restore ConfigMap loading.
Precedence: per-restore modifier takes exclusive precedence over the
default. Default ConfigMap errors are non-fatal (warn and proceed).
SkipDefaultResourceModifier opt-out is respected.
Includes unit tests covering: default-only, per-restore override,
skip flag, missing default (non-fatal), missing per-restore (fatal),
and no modifier configured.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Add DefaultResourceModifierConfigMap field to the server Config struct
and bind it as a CLI flag. When set, it references a ConfigMap name in
the Velero namespace containing default resource modifier rules to apply
to all restores.
Follows the existing pattern used by --backup-repository-configmap and
--repo-maintenance-job-configmap.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
* Support set-based filter label selectors
Use matchLabels/matchExpressions in fine-grained filters.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
* omit the details of resource policy for cli
The reason to not resolve and display CLI is because it may go
out of sync, we want to avoid display it to mislead users.
We may consider to cpature those information and display it
in later release.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
---------
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Co-authored-by: Scott Seago <sseago@redhat.com>
Added CLI for creating restore resource policies, and view
the resource policies associated with resource if present.
Only list the name of the configmap for now.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
* Add change-id and volume-id retrieve logic for both vks and vanilla k8s environment.
* Add change-id and volume-id support code in exposer.
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
Change errors.Cause to errors.Is, because github.com/cockroachdb/errors
New() function create a error with error stack with depth 1, but
github.com/pkg/errors's New() function create error with no depth.
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
Chlins ZhangandGitHub
Adam ZhangandGitHub
PranjalandGitHub
R4mboandGitHub
Xun Jiang/Bruce JiangandGitHub
Xun Jiang
opbot_xd
lyndon-liandGitHub
Jay SawantandGitHub
Shubham Pampattiwar
Lyndon-Li
