Volume Reconstruction migration design

1 files changed, 23 insertions, 1 deletions

diff --git a/contributors/design-proposals/storage/csi-migration.md b/contributors/design-proposals/storage/csi-migration.md
index 5aa7411c..db5a0142 100644
--- a/contributors/design-proposals/storage/csi-migration.md
+++ b/contributors/design-proposals/storage/csi-migration.md
@@ -268,7 +268,29 @@ TODO: Design
 
 ### Volume Reconstruction
 
-TODO: Design
+Volume Reconstruction is currently a routine in the reconciler that runs on the
+nodes when a Kubelet restarts and loses its cached state (`desiredState` and
+`actualState`). It is kicked off in `syncStates()` in
+`pkg/kubeletvolumemanager/reconciler/reconciler.go` and attempts to reconstruct
+a volume based on the mount path on the host machine.
+
+When CSI Migration is turned on, when the reconstruction code is run and it
+finds a CSI mounted volume we currently do not know whether it was mounted as a
+native CSI volume or migrated from in-tree. To solve this issue we will save a
+`migratedVolume` boolean in the `saveVolumeData` function when the `NewMounter`
+is created during the `MountVolume` call for that particular volume in the
+Operation generator.
+
+When the Kubelet is restarted and we lose state the Kubelet will call
+`reconstructVolume` we can `loadVolumeData` and determine whether that CSI
+volume was migrated or not, as well as get the information about the original
+plugin requested. With that information we should be able to call the
+`ReconstructVolumeOperation` with the correct in-tree plugin to get the original
+in-tree spec that we can then pass to the rest of volume reconstruction. The
+rest of the volume reconstruction code will then use this in-tree spec passed to
+the `desiredState`, `actualState`, and `operationGenerator` and the volume will
+go through the standard volume pathways and go through the standard migrated
+volume lifecycles described above in the "Pre-Provisioned Volumes" section.
 
 ### Volume Limit