diff options
| author | Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com> | 2019-03-26 18:54:48 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-03-26 18:54:48 -0700 |
| commit | f41ba061c99b503b51c9f296fe60c13946ad9092 (patch) | |
| tree | 1ff3bf9e130721924e52be8990d634227e844ca3 | |
| parent | 92a50cbb510d27ba5d6a91cccbea60a3cd3c3c3e (diff) | |
| parent | 96ba398a4060d6ad836f25151ee8341d31514eea (diff) | |
Merge pull request #3295 from davidz627/feature/reconstructionMigration
Volume Reconstruction migration design
| -rw-r--r-- | contributors/design-proposals/storage/csi-migration.md | 24 |
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 fab6592c..2dc03170 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 |