Fix broken links in design docs (#10573)

Links to plugin-versioning.md and general-progress-monitoring.md broke when
those docs moved to design/Implemented/; two other relative paths had one
directory level wrong.

Signed-off-by: Zain <43629888+ZainnQureshii@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Zain Qureshi
2026-09-24 11:41:03 +08:00
committed by GitHub
co-authored by Claude Opus 5.5
parent 8f438e0b8e
commit 7adda843e4
3 changed files with 5 additions and 5 deletions
@@ -1,7 +1,7 @@
# Plugin Progress Monitoring
This is intended as a replacement for the previously-approved Upload Progress Monitoring design
([Upload Progress Monitoring](upload-progress.md)) in order to expand the supported use cases beyond
([Upload Progress Monitoring](../upload-progress.md)) in order to expand the supported use cases beyond
snapshot uploads to include what was previously called Async Backup/Restore Item Actions. This
updated design should handle the combined set of use cases for those previously separate designs.
@@ -230,7 +230,7 @@ That matches BIA must-include semantics (plugin-trusted hard dependencies), rath
### Interaction with fine-grained restore filters
Per [Fine Grained Restore Filters via Resource Policies](../restore-filter-enhancement/fine-grained-restore-filters-design.md), plugin additional items already bypass `namespacedFilterPolicies` / `clusterScopedFilterPolicy` kind, name, and label checks.
Per [Fine Grained Restore Filters via Resource Policies](restore-filter-enhancement/fine-grained-restore-filters-design.md), plugin additional items already bypass `namespacedFilterPolicies` / `clusterScopedFilterPolicy` kind, name, and label checks.
Those filters live in the selection phases; additional items enter `restoreItem()` directly.
This proposal only changes the remaining global gates inside `restoreItem()`.
+3 -3
View File
@@ -1,7 +1,7 @@
# Design for VolumeSnapshotter v2 API
## Abstract
This design includes the changes to the VolumeSnapshotter api design as required by the [Item Action Progress Monitoring](general-progress-monitoring.md) feature.
This design includes the changes to the VolumeSnapshotter api design as required by the [Item Action Progress Monitoring](Implemented/general-progress-monitoring.md) feature.
The VolumeSnapshotter v2 interface will have two new methods.
If there are any additional VolumeSnapshotter API changes that are needed in the same Velero release cycle as this change, those can be added here as well.
@@ -18,7 +18,7 @@ This will allow long-running plugin actions to continue in the background while
## High-Level Design
As per the [Plugin Versioning](plugin-versioning.md) design, a new VolumeSnapshotterv2 plugin `.proto` file will be created to define the GRPC interface.
As per the [Plugin Versioning](Implemented/plugin-versioning.md) design, a new VolumeSnapshotterv2 plugin `.proto` file will be created to define the GRPC interface.
v2 go files will also be created in `plugin/clientmgmt/volumesnapshotter` and `plugin/framework/volumesnapshotter`, and a new PluginKind will be created.
The velero Backup process will be modified to reference v2 plugins instead of v1 plugins.
An adapter will be created so that any existing VolumeSnapshotter v1 plugin can be executed as a v2 plugin when executing a backup.
@@ -74,7 +74,7 @@ message OperationProgress {
```
A new PluginKind, `VolumeSnapshotterV2`, will be created, and the backup process will be modified to use this plugin kind.
See [Plugin Versioning](plugin-versioning.md) for more details on implementation plans, including v1 adapters, etc.
See [Plugin Versioning](Implemented/plugin-versioning.md) for more details on implementation plans, including v1 adapters, etc.
## Compatibility