From c827b739e9a5895a04d62c673c71f917a12d5b1f Mon Sep 17 00:00:00 2001 From: lijianfeng1993 Date: Tue, 6 Feb 2018 18:30:58 +0800 Subject: [PATCH] fix a typo --- .../cloud-provider/cloud-provider-refactoring.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributors/design-proposals/cloud-provider/cloud-provider-refactoring.md b/contributors/design-proposals/cloud-provider/cloud-provider-refactoring.md index 0d25ccab0..99c034785 100644 --- a/contributors/design-proposals/cloud-provider/cloud-provider-refactoring.md +++ b/contributors/design-proposals/cloud-provider/cloud-provider-refactoring.md @@ -105,7 +105,7 @@ Kube-apiserver uses the cloud provider for two purposes ### 5. Strategy for refactoring Volumes -Volumes need cloud providers, but they only need SPECIFIC cloud providers. The majority of volume management logic resides in the controller manager. These controller loops need to be moved into the cloud-controller manager. The cloud controller manager also needs a mechanism to read parameters for initilization from cloud config. This can be done via config maps. +Volumes need cloud providers, but they only need SPECIFIC cloud providers. The majority of volume management logic resides in the controller manager. These controller loops need to be moved into the cloud-controller manager. The cloud controller manager also needs a mechanism to read parameters for initialization from cloud config. This can be done via config maps. There is an entirely different approach to refactoring volumes - Flex Volumes. There is an undergoing effort to move all of the volume logic from the controller-manager into plugins called Flex Volumes. In the Flex volumes world, all of the vendor specific code will be packaged in a separate binary as a plugin. After discussing with @thockin, this was decidedly the best approach to remove all cloud provider dependency for volumes out of kubernetes core.