diff --git a/contributors/design-proposals/storage/csi-migration.md b/contributors/design-proposals/storage/csi-migration.md index fab6592cf..2dc03170f 100644 --- a/contributors/design-proposals/storage/csi-migration.md +++ b/contributors/design-proposals/storage/csi-migration.md @@ -302,7 +302,29 @@ for where is it used before the translation. ### 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