* Support overriding Schedule annotations via template.metadata.annotations
Adds an Annotations field to BackupSpec.Metadata, mirroring the existing
Labels override. When Schedule.Spec.Template.Metadata.Annotations is set,
it is used for the resulting Backup's annotations instead of copying
Schedule.Annotations directly, allowing users to opt out of unwanted
annotations (e.g. ArgoCD tracking annotations) being propagated from
Schedule to Backup.
Fixes#5836
Signed-off-by: Lubron Zhan <lubronzhan@gmail.com>
* Rename changelog fragment to match PR number 10045
Signed-off-by: Lubron Zhan <lubronzhan@gmail.com>
---------
Signed-off-by: Lubron Zhan <lubronzhan@gmail.com>
Co-authored-by: Daniel Jiang <daniel.jiang@broadcom.com>
Stop force-including VolumeSnapshotContents via resourceMustHave on
every restore; CSI VolumeSnapshot/PVC RestoreItemActions now set
`restore.velero.io/must-include-additional-items` so bound snapshot
dependencies are restored only when their parent is restored.
Fixes: #9957
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Let RestoreItemActions opt in via annotation to
bypass global restore filters for AdditionalItems,
mirroring the backup-side must-include behavior.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Update the landing page CTA link from the outdated Velero 1.11 blog
post to the GitHub releases/latest URL, which always resolves to the
most recent release and will not go stale.
Fixes#10080
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Add a GetSnapshotClass method to VolumeHelper that encapsulates the
extraction of the snapshotClass parameter from volume policy actions.
This avoids requiring callers to parse raw parameters from
GetActionParameters. Simplify the CSI plugin to use the new method.
Ref: #8807
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Verify that when a volume policy specifies snapshotClass, the CSI
plugin creates a VolumeSnapshot using that VolumeSnapshotClass. The
test uses a VSC without the velero label to confirm selection comes
from the volume policy parameter, not the label-based fallback.
Ref: #8807
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Add documentation for the new snapshotClass parameter in the volume
policy snapshot action. Update the CSI docs to include volume policy
as a tier in the VolumeSnapshotClass selection priority, and add
Example 6 to resource-filtering.md showing multi-array usage.
Ref: #8807
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
In pvcBackupItemAction.Execute, call GetActionParameters to extract the
snapshotClass from the matched volume policy and pass it through
getVolumeSnapshotReference and createVolumeSnapshot to
GetVolumeSnapshotClass. This connects the volume policy parameter to
the CSI snapshot creation path.
Fixes#8807
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Add GetVolumeSnapshotClassFromVolumePolicy helper and extend
GetVolumeSnapshotClass with a policySnapshotClass parameter. The new
tier sits between PVC annotation and backup annotation in the priority
chain: PVC annotation > volume policy > backup annotation > VSC label.
Ref: #8807
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Validate the snapshotClass parameter in Action.validate(): it must only
appear on snapshot actions, must be a string, and must not be empty.
Follows the same validation pattern as the dataMover parameter.
Ref: #8807
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Add a new snapshotClass action parameter to volume policies, allowing
users to specify which VolumeSnapshotClass to use for CSI snapshots.
This follows the existing dataMover parameter pattern with a typed
constant and getter method on the Action struct.
Ref: #8807
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>
* Derive Ginkgo CLI version from go.mod in test/Makefile
Hardcoded @v2.22.0 pin drifted from go.mod's v2.28.3, causing
Ginkgo CLI/package version mismatch warnings.
Fixes#10023
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* Derive protoc-gen-go and goimports versions from go.mod in build-image
Same drift issue as #10023: Dockerfile hardcoded @v1.33.0 and @v0.33.0
while go.mod had moved on. Build context is hack/build-image, which
doesn't include go.mod, so versions are computed in the Makefile (which
does have go.mod) and passed through as build-args, same as GOPROXY.
protoc-gen-go-grpc and controller-gen/setup-envtest/golangci-lint are
left as-is: no matching go.mod entry, or independently versioned from
the module they live alongside.
Fixes#10023
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
---------
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
The test assumed all ten Write calls succeed before any async goroutine
stores its error, but with a mock that fails instantly a goroutine can
poison the writer mid-loop, making a later Write correctly fail fast —
a timing-dependent test failure.
Rewrite the test to assert the real-world contract instead of one
schedule: a failed async block write either fails a subsequent Write
fast or surfaces at Result, and is never lost. Add a separate
deterministic case pinning the late-error schedule, holding async
writes until all writes are queued so Result alone must report the
error.
Verified with -race -count=100.
Fixes#10029
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>