Updated vsphere multi disk enhancement.

Author: vr4manta

Diff for: enhancements/machine-api/vsphere-data-disk.md

@@ -110,10 +110,13 @@ compute:
       dataDisks:
       - diskSizeGiB: 10
         name: "container_images"
+        provisioningMode: "Thin"
       - diskSizeGiB: 20
         name: "log files"
+        provisioningMode: "Thick"
       - diskSizeGiB: 30
         name: "swap"
+        provisioningMode: "EagerlyZeroed"
   replicas: 0
 controlPlane:
   architecture: amd64
@@ -131,13 +134,15 @@ controlPlane:
       dataDisks:
       - diskSizeGiB: 10
         name: "etcd"
+        provisioningMode: "Thick"
       - diskSizeGiB: 20
         name: "container-images"
+        provisioningMode: "Thin"
   replicas: 3
 ...
 ```
 
-In the example above, we have added a new field `dataDisks` that is used to define each of the disks to create for the virtual machine.  The `name` field is used to identify the disk.  This is used primarily for debug and for identifying the disk definition.  The `diskSizeGiB` field specifies how large the disk needs to be.
+In the example above, we have added a new field `dataDisks` that is used to define each of the disks to create for the virtual machine.  The `name` field is used to identify the disk.  This is used primarily for debug and for identifying the disk definition.  The `diskSizeGiB` field specifies how large the disk needs to be. The `provisioningMode` field specifies how the disk should be provisioned.  This field supports the values of "Thin", "Thick", and "EagerlyZeroed"
 
 #### API
 
@@ -156,15 +161,48 @@ type VSphereMachineProviderSpec struct {
 
 // VSphereDisk describes additional disks for vSphere.
 type VSphereDisk struct {
-    // name is a name to be used to identify the disk definition. If name is not specified,
-    // the disk will still be created.  The name should be unique so that it can be used to clearly
-    // identify purpose of the disk, but is not required to be unique.
-    // +optional
+    // name is used to identify the disk definition. name is required needs to be unique so that it can be used to
+    // clearly identify purpose of the disk.
+    // It must be at most 80 characters in length and must consist only of alphanumeric characters, hyphens and underscores,
+    // and must start and end with an alphanumeric character.
+    // +kubebuilder:example=images_1
+    // +kubebuilder:validation:MaxLength=80
+    // +kubebuilder:validation:Pattern="^[a-zA-Z0-9]([-_a-zA-Z0-9]*[a-zA-Z0-9])?$"
+    // +required
     Name string `json:"name,omitempty"`
-    // sizeGiB is the size of the disk (in GiB).
-    // +kubebuilder:validation:Required
+    // sizeGiB is the size of the disk in GiB.
+    // The maximum supported size 16384 GiB.
+    // +kubebuilder:validation:Minimum=1
+    // +kubebuilder:validation:Maximum=16384
+    // +required
     SizeGiB int32 `json:"sizeGiB"`
+    // provisioningMode is an optional field that specifies the provisioning type to be used by this vSphere data disk.
+    // Allowed values are "Thin", "Thick", "EagerlyZeroed", and omitted.
+    // When set to Thin, the disk will be made using thin provisioning allocating the bare minimum space.
+    // When set to Thick, the full disk size will be allocated when disk is created.
+    // When set to EagerlyZeroed, the disk will be created using eager zero provisioning. An eager zeroed thick disk has all space allocated and wiped clean of any previous contents on the physical media at creation time. Such disks may take longer time during creation compared to other disk formats.
+    // When omitted, no setting will be applied to the data disk and the provisioning mode for the disk will be determined by the storage policy attached to the datastore.
+    // +optional
+    ProvisioningMode ProvisioningMode `json:"provisioningMode,omitempty"`
 }
+
+// provisioningMode represents the various provisioning types available to a VMs disk.
+// +kubebuilder:validation:Enum=Thin;Thick;EagerlyZeroed
+type ProvisioningMode string
+
+const (
+    // ProvisioningModeThin creates the disk using thin provisioning. This means a sparse (allocate on demand)
+    // format with additional space optimizations.
+    ProvisioningModeThin ProvisioningMode = "Thin"
+
+    // ProvisioningModeThick creates the disk with all space allocated.
+    ProvisioningModeThick ProvisioningMode = "Thick"
+
+    // ProvisioningModeEagerlyZeroed creates the disk using eager zero provisioning. An eager zeroed thick disk
+    // has all space allocated and wiped clean of any previous contents on the physical media at
+    // creation time. Such disks may take longer time during creation compared to other disk formats.
+    ProvisioningModeEagerlyZeroed ProvisioningMode = "EagerlyZeroed"
+)
 ```
 
 Examples of the various CRs using the above type enhancement:
@@ -217,8 +255,10 @@ spec:
             dataDisks:
             - diskSizeGiB: 10
               name: "etcd"
+              provisioningMode: "Thick"
             - diskSizeGiB: 20
               name: "container-images"
+              provisioningMode: "Thin"
             diskGiB: 100
             kind: VSphereMachineProviderSpec
             memoryMiB: 16384
@@ -278,8 +318,10 @@ spec:
       dataDisks:
       - diskSizeGiB: 10
         name: "etcd"
+        provisioningMode: "Thick"
       - diskSizeGiB: 20
         name: "container-images"
+        provisioningMode: "Thin"
       diskGiB: 100
       kind: VSphereMachineProviderSpec
       memoryMiB: 16384
@@ -342,10 +384,13 @@ spec:
           dataDisks:
           - diskSizeGiB: 10
             name: "container_images"
+            provisioningMode: "Thin"
           - diskSizeGiB: 20
             name: "log files"
+            provisioningMode: "Thick"
           - diskSizeGiB: 30
             name: "swap"
+            provisioningMode: "EagerlyZeroed"
           diskGiB: 60
           kind: VSphereMachineProviderSpec
           memoryMiB: 8192
@@ -384,11 +429,11 @@ N/A
 
 ### Implementation Details/Notes/Constraints
 
-What are some important details that didn't come across above in the
-**Proposal**? Go in to as much detail as necessary here. This might be
-a good place to talk about core concepts and how they relate. While it is useful
-to go into the details of the code changes required, it is not necessary to show
-how the code will be rewritten in the enhancement.
+Many of the choices made above were based on how CAPV implemented the feature.  This was to make sure we keep these APIs in sync with CAPI so that we can migrate our existing infrastructure to CAPI implementation in the future.  
+
+The installer is responsible for initially setting up the cluster with the data disks configurations for the control plane nodes.  The installer is preconfiguring a machineset for compute nodes as well but can be modified in day 2+. The installer is also leveraging CAPI to install the control plane VMs.  We have updated installer to use latest version of CAPV to get access to the upstream changes for this feature.  The CPMS definition also has been enhanced to allow the CPMS operator to monitor changes in the disk configs.
+
+The data disk configs are allowing the administrator to configure each data disk individually for provisioning mode.  The installer today via the install-config.yaml does allow the administrator to set the provisioning mode used on the template's clone process.  This configuration setting will also be used by govmomi / vCenter when creating the VMs data disks if the data disk config has omitted the provisioning mode field.
 
 ### Risks and Mitigations
 
@@ -402,6 +447,8 @@ N/A
 
 > 1. Are there any other disk configuration options that we must add in order for this feature to be GA ready?  Is keeping it simple w/ just size enough for GA or just TP?
 
+     Update: Added ability to set provisioning mode for each disk has been added to address allowing admins to set each disk specifically for their needs.
+
 ## Test Plan
 
 - We will add an automated test to CI to test installing a cluster with data disks assigned to both control plane and compute nodes.