When a user specifies a Custom Resource Kind in a restore filter
policy (e.g., kinds: [MyCustomKind]), the discovery helper fails
to resolve it if the CRD hasn't been restored yet.
This adds a peek-and-map fallback: if a resource type in the
backup tarball doesn't match the resolved filters, Velero peeks
at the actual Kind of the first item in the tarball and matches
it against the user's original policy strings.
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>
- Use *bool for SkipDefaultResourceModifier to match RestoreSpec conventions
- Use boolptr.IsSetToTrue for nil-safe bool check in controller logic
- Fix warning message to say "failed to retrieve" instead of "not found"
- Add Restore Describe Output subsection covering all resolved states
- Only set SkipDefaultResourceModifier from CLI when flag is true
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
restore filters via resource policy, support ClusterScopedFilterPolicy
and NamespaceFilterPolicies.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
For resource policy in restore, it will reject invalid sections
such as volumePolicies or includeExcludePolicy, to prevent user
from misuse backup side resource policy configmap.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Add resourcePolicy field for restore CRD which is backed by
a configmap that holds ClusterScopedFilterPolicy and
NamespacedFilterPolicies for restore side filtering.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Fixes a flaky test in TestWaitExecHandleHooks:
"should return no error with 2 spec hooks in 2 different containers,
1st container starts running after 10ms, 2nd container after 20ms,
both succeed"
Observed failure (CI run https://github.com/velero-io/velero/actions/runs/28119573625/job/83267758421):
mock: Unexpected Method Call
ExecutePodCommand called with resourceVersion:"3" (both containers running),
but mock was registered expecting resourceVersion:"2" (container1 running,
container2 still waiting).
Root cause: the two source.Modify calls were 10ms apart. The informer's
DeltaFIFO queue can coalesce rapid updates, delivering only the latest pod
state (resourceVersion:3) to the handler before the hook for container1 fires.
The comment "each of these states will be seen by the UpdateFunc handler" was
incorrect — intermediate states can be silently skipped under load.
Fix: add waitForSignal chan struct{} to the change struct and onCalled func()
to the expectedExecution struct. The goroutine now blocks after sending the
first change until the mock signals that the hook has fired (via close), then
sends the second change. This guarantees the handler observes the intermediate
pod state (resourceVersion:2) when executing container1's hook.
Signed-off-by: Lubron Zhan <lubronzhan@gmail.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Extract pkg/apis into a standalone Go module with its own go.mod/go.sum,
and wire it back into the main module via a local replace directive.
Signed-off-by: Lubron Zhan <lubronzhan@gmail.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Adam Zhang
dependabot[bot]andGitHub
Xun Jiang/Bruce JiangandGitHub
lyndon-liandGitHub
copilot-swe-agent[bot]andGitHub
Scott Seagoandaider
Xun Jiang
Lyndon-Li
Shubham Pampattiwar
Chlins ZhangandGitHub
Lubron ZhanandClaude Sonnet 4.6