Skip to content

Conversation

@AleksZimin
Copy link
Member

No description provided.

Signed-off-by: Aleksandr Zimin <alexandr.zimin@flant.com>
Neumoin, Konstantin and others added 18 commits December 16, 2025 13:07
Signed-off-by: Aleksandr Zimin <alexandr.zimin@flant.com>
- Read StorageClass via APIReader only
- Remove local Condition/Reason constants
- Enforce UID barrier for OwnerReferences
- Unify terminal Ready semantics
Replace all occurrences of fox.flant.com/deckhouse/storage/storage-foundation
with github.com/deckhouse/storage-foundation in go.mod files and imports.

- Update module paths in api/go.mod and images/controller/go.mod
- Update all import statements across the codebase
- Fix missing imports in test files
- Remove unused getVolumeMode, getSize, checkAndHandleTTL functions
- Fix TTL scanner runnable logic in AddVolumeRestoreRequestControllerToManager
- Improve test reliability: strict terminal state checks, proper Status subresource usage
- Update ensureObjectKeeper comment for UID handling
…sioner.

This change allows external-provisioner to react to VolumeRestoreRequest objects and perform a restore operation by creating a CSI volume and corresponding Kubernetes PersistentVolume and PersistentVolumeClaim.

Key changes:
	•	Introduce a VRR handler wired via a dynamic informer
	•	Restore volumes from:
	•	VolumeSnapshotContent using CSI VolumeContentSource_Snapshot
	•	PersistentVolume using CSI clone (VolumeContentSource_Volume)
	•	Enforce strict driver filtering: VRR is processed only when StorageClass.provisioner matches the current provisioner
	•	Extract and reuse PV creation logic from existing provisioner code paths
	•	Ensure idempotent behavior:
	•	Handle cases where PV already exists from a previous attempt
	•	Safely continue to PVC creation even after partial execution
	•	Tolerate concurrent PV creation races
	•	Correctly propagate CSI semantics:
	•	Volume capabilities, access modes, volume ing for MULTI_NODE_READER_ONLY
	•	Topology information to PV node affinity
	•	Emit Kubernetes Events for success and failure
	•	Do not update VRR status or manage restore lifecycle

The external-provisioner performs best-effort execution only; retry policy, lifecycle management, and terminal state handling are delegated to higher-level controllers.
Transform VRRHandler from stateless executor to operation controller that
owns the restore lifecycle. This aligns with ADR v2 where external-provisioner
is responsible for restore execution, terminal decisions, and VRR.status updates.

Key changes:
- Add waitForPVCBound() to poll PVC status until Bound or timeout
- Add updateVRRStatus() with retry-on-conflict for robust status updates
- Add updateVRRReady() and updateVRRFailed() helpers
- Add isTerminalVRR() check to skip already-terminal VRRs
- Fix execution order: driver filter MUST be first executable step after
  minimal validation (security invariant for multi-CSI clusters)
- Update RBAC to grant write permissions for volumerestorerequests/status
- Add terminal VRR check after driver filter to avoid logging about
  VRRs from other drivers
- Add idempotency check (PVC Get) after driver filter to prevent accessing
  resources from other drivers

Testing:
- Add fake dynamic client support for VRR status updates in tests
- Add PVC reactor to automatically set Phase=Bound when VolumeName is set
- Add addVRRToDynamicClient() helper for test setup
- All existing tests pass with new controller behavior

Documentation:
- Update vrr-restore-implementation-plan.md to reflect operation controller role
- Remove "single-writer contract" and "stateless executor" references
- Clarify retry semantics and terminal state ownership
- Document polling rationale for waitForPVCBound

Vendor:
- Add storage-foundation/api module to vendor for -mod=vendor compatibility

This completes Stage 6 (PVC Bound waiting and status updates) from the
implementation plan.
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.

3 participants