openshift-velero-plugin: velero dependency stale on master (no rebase-config) and ~22mo behind on oadp-dev/release branches

[kaovilai]

Note

Responses generated with Claude

Summary

openshift/openshift-velero-plugin's github.com/openshift/velero dependency is out of date in two distinct ways:

1. master branch has no rebase-config at all

master's go.mod pins:

github.com/vmware-tanzu/velero v1.7.0
replace github.com/vmware-tanzu/velero => github.com/openshift/velero v0.10.2-0.20210728132925-bab294f5d24c

That pseudo-version resolves to the tip of openshift/velero's konveyor-1.6.2 branch (SHA bab294f5d24c...), dated 2021-07-28 — a pre-OADP/Konveyor-era branch, ~5 years old.

Checking rebase-configs/ in this repo, openshift_openshift_velero_plugin only has configs for oadp-dev, oadp-1.3, oadp-1.4, oadp-1.5, and oadp-1.6 — there's no master config. So master appears to be structurally outside the wave-rebase automation's reach entirely (never picked up, by design or oversight).

2. oadp-dev branch itself is ~22 months behind, despite having an active config

openshift-velero-plugin's oadp-dev branch go.mod pins:

replace github.com/vmware-tanzu/velero => github.com/openshift/velero v0.10.2-0.20240919150610-92244630d90b

dated 2024-09-19. But openshift/velero's own oadp-dev branch (the actual rebase target) was last updated just 4 days ago:

commit e2178e7e "Merge pull request #494 from oadp-rebasebot/rebase-bot-oadp-dev — Merge velero-io/velero:main (c825e3c) into oadp-dev", 2026-07-16

So Wave II (rebasing openshift/velero itself) is clearly running on schedule, but Wave IV propagation of that into openshift-velero-plugin hasn't landed in ~22 months. There's no pending/stuck PR either — the rebase-bot-oadp-dev branch on oadp-rebasebot/openshift-velero-plugin is at the same SHA as oadp-dev, i.e. rebasebot isn't currently sitting on unmerged work for this repo, it's just not been run/scheduled.

Why this matters

While working on openshift/openshift-velero-plugin#448, we hit concrete plugin-authoring constraints caused by the stale (2021) Velero API pinned on master:

• pkg/restore/restore.go unconditionally skips Namespace objects from ever reaching the RestoreItemAction plugin pipeline (hardcoded special case).
• RestoreItemActionExecuteOutput has no Warning field, so plugins can't add non-fatal warnings to a restore's status.

Both may have changed in newer Velero versions — impossible to know without the dependency being current. Given oadp-dev and the release branches carry the actual product builds, having them ~22 months behind matters more directly, but master being entirely unmanaged is also worth a decision either way.

Questions

1. Is master intentionally excluded from rebase-config coverage (e.g. treated as a Konveyor-upstream-only branch, not an OADP product branch)? If not, should a rebase-configs/openshift_openshift_velero_plugin_master.env.sh be added?
2. Why hasn't Wave IV propagation (openshift/velero → openshift-velero-plugin) run for oadp-dev/release branches in ~22 months — disabled, blocked, or just not scheduled/prioritized?