Skip to content

Watch VolumeSnapshotContent to wake the owning VolumeCaptureRequest#49

Open
kneumoin wants to merge 3 commits into
mainfrom
latency-cut
Open

Watch VolumeSnapshotContent to wake the owning VolumeCaptureRequest#49
kneumoin wants to merge 3 commits into
mainfrom
latency-cut

Conversation

@kneumoin

Copy link
Copy Markdown
Contributor

Stamp VCR-coordinate labels on the CSI VolumeSnapshotContent at creation and add a VSC watch that maps a readyToUse/error transition straight back to the owning VolumeCaptureRequest, so it reconciles immediately instead of waiting for the 5s requeue tick. The requeue remains as a safety net.

Description

Why do we need it, and what problem does it solve?

What is the expected result?

Checklist

  • The code is covered by unit tests.
  • e2e tests passed.
  • Documentation updated according to the changes.
  • Changes were tested in the Kubernetes cluster manually.

kneumoin added 3 commits June 30, 2026 14:30
Stamp VCR-coordinate labels on the CSI VolumeSnapshotContent at creation and
add a VSC watch that maps a readyToUse/error transition straight back to the
owning VolumeCaptureRequest, so it reconciles immediately instead of waiting
for the 5s requeue tick. The requeue remains as a safety net.
…-leg latency

Raise the VolumeCaptureRequest controller concurrency from implicit 1 to 4 with a
bounded rate limiter (200ms->10s). Independent VCRs own UID-scoped ObjectKeeper and
VolumeSnapshotContent names, hold no shared mutable state (Config is read-only), and
status writes use RetryOnConflict, so parallel reconciles of distinct VCRs are safe.
This parallelizes the capture leg that serialized concurrent tree snapshots.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant