Skip to content

Commit bf459c1

Browse files
committed
Created vsphere multi disk enhancement.
1 parent 383f9d3 commit bf459c1

File tree

1 file changed

+35
-77
lines changed

1 file changed

+35
-77
lines changed

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

+35-77
Original file line numberDiff line numberDiff line change
@@ -50,52 +50,41 @@ Today the machine API does not allow for vSphere machines to be able to be confi
5050

5151
### Workflow Description
5252

53-
Explain how the user will use the feature. Be detailed and explicit.
54-
Describe all of the actors, their roles, and the APIs or interfaces
55-
involved. Define a starting state and then list the steps that the
56-
user would need to go through to trigger the feature described in the
57-
enhancement. Optionally add a
58-
[mermaid](https://github.com/mermaid-js/mermaid#readme) sequence
59-
diagram.
60-
61-
Use sub-sections to explain variations, such as for error handling,
62-
failure recovery, or alternative outcomes.
63-
64-
For example:
65-
66-
**cluster creator** is a human user responsible for deploying a
67-
cluster.
68-
69-
**application administrator** is a human user responsible for
70-
deploying an application in a cluster.
71-
72-
1. The cluster creator sits down at their keyboard...
73-
2. ...
74-
3. The cluster creator sees that their cluster is ready to receive
75-
applications, and gives the application administrator their
76-
credentials.
77-
78-
See
79-
https://github.com/openshift/enhancements/blob/master/enhancements/workload-partitioning/management-workload-partitioning.md#high-level-end-to-end-workflow
80-
and https://github.com/openshift/enhancements/blob/master/enhancements/agent-installer/automated-workflow-for-agent-based-installer.md for more detailed examples.
53+
**_Installation with data disks_**
54+
55+
1. User create install-config.yaml with machine pools containing data disk configuration
56+
2. User runs the `openshift-install` program to start the creation of new cluster
57+
3. Installer generates configs for CAPI to create the control plane machines
58+
4. Installer generates configs for cluster CPMS, control plane machine, and compute machines sets with the machine pool information applied (including new data disk configs)
59+
5. CAPI / CAPV creates the control plane VMs in vSphere
60+
6. MAPI creates any compute nodes that were configured to be created at install time
61+
7. Cluster creation completes with all desired VMs / nodes operational as well as all Cluster Operators reporting Available with no errors.
62+
63+
**_Machine Set Creation_**
64+
65+
1. User creates new machine set configuration with the vsphere machine provider spec containing data disks
66+
2. User runs `oc create -f <filename>` to create the new machine set
67+
3. User scales up machine set
68+
4. MAPI creates new VM in vSphere and requests new disks be dynamically added to the VM during the cloning process
69+
5. Machine state progresses to `Provisioned`
70+
6. The VM is started after the cloning process completes
71+
7. The new VM provisions successfully and the node is created in OpenShift
72+
8. The Machine state progresses to `Running`
73+
9. The MachineSet shows desired, current, ready, and available all with the correct counts
74+
75+
**_Machine Creation (No MachineSet)_**
76+
77+
1. User creates new machine configuration with the vsphere machine provider spec containing data disks
78+
2. User runs `oc create -f <filename>` to create the new machine
79+
3. MAPI creates new VM in vSphere and requests new disks be dynamically added to the VM during the cloning process
80+
4. The Machine state transitions to `Provisioned`
81+
5. The VM is started
82+
6. The new VM starts successfully and the node is created in OpenShift
83+
7. The Machine state transitions to `Running`
8184

8285
### API Extensions
8386

84-
API Extensions are CRDs, admission and conversion webhooks, aggregated API servers,
85-
and finalizers, i.e. those mechanisms that change the OCP API surface and behaviour.
86-
87-
- Name the API extensions this enhancement adds or modifies.
88-
- Does this enhancement modify the behaviour of existing resources, especially those owned
89-
by other parties than the authoring team (including upstream resources), and, if yes, how?
90-
Please add those other parties as reviewers to the enhancement.
91-
92-
Examples:
93-
- Adds a finalizer to namespaces. Namespace cannot be deleted without our controller running.
94-
- Restricts the label format for objects to X.
95-
- Defaults field Y on object kind Z.
96-
97-
Fill in the operational impact of these API Extensions in the "Operational Aspects
98-
of API Extensions" section.
87+
This enhancement will be enhancing the installer's CRD / type used for the install-config.yaml and will also be enhancing the vsphere machine provider spec type and all dependent CRDs.
9988

10089
#### Installer
10190

@@ -458,47 +447,16 @@ Upgrade expectations:
458447
Downgrade expectations:
459448
460449
- If upgrade succeeded and new machines were configured to use data disks, these configuration must be undone before downgraded due to CRD incompatibility.
461-
- Deleting any CVO-managed resources added by the new version. The CVO does not currently delete resources that no longer exist in the target version.
450+
- Rollback of install will convert the CRDs back to a supported state. There is no manual need to remove any CRDs since no new CRDs are introduced.
462451
463452
## Version Skew Strategy
464453
465454
N/A
466455
467456
## Operational Aspects of API Extensions
468457
469-
Describe the impact of API extensions (mentioned in the proposal section, i.e. CRDs,
470-
admission and conversion webhooks, aggregated API servers, finalizers) here in detail,
471-
especially how they impact the OCP system architecture and operational aspects.
472-
473-
- For conversion/admission webhooks and aggregated apiservers: what are the SLIs (Service Level
474-
Indicators) an administrator or support can use to determine the health of the API extensions
475-
476-
Examples (metrics, alerts, operator conditions)
477-
- authentication-operator condition `APIServerDegraded=False`
478-
- authentication-operator condition `APIServerAvailable=True`
479-
- openshift-authentication/oauth-apiserver deployment and pods health
480-
481-
- What impact do these API extensions have on existing SLIs (e.g. scalability, API throughput,
482-
API availability)
483-
484-
Examples:
485-
- Adds 1s to every pod update in the system, slowing down pod scheduling by 5s on average.
486-
- Fails creation of ConfigMap in the system when the webhook is not available.
487-
- Adds a dependency on the SDN service network for all resources, risking API availability in case
488-
of SDN issues.
489-
- Expected use-cases require less than 1000 instances of the CRD, not impacting
490-
general API throughput.
491-
492-
- How is the impact on existing SLIs to be measured and when (e.g. every release by QE, or
493-
automatically in CI) and by whom (e.g. perf team; name the responsible person and let them review
494-
this enhancement)
495-
496-
- Describe the possible failure modes of the API extensions.
497-
- Describe how a failure or behaviour of the extension will impact the overall cluster health
498-
(e.g. which kube-controller-manager functionality will stop working), especially regarding
499-
stability, availability, performance and security.
500-
- Describe which OCP teams are likely to be called upon in case of escalation with one of the failure modes
501-
and add them as reviewers to this enhancement.
458+
- Addition of data disks to VMs adds marginal time to creation (clone) of each virtual machine. The amount of time is negligible compared to the cloning process as a whole.
459+
- New vmdk files will be created for each machine that will be present in the VM's folder in vCenter. The naming of the new disk files will follow that of the primary disk. This is normally the VM's name with _# at the end where # is the index the disk is configured in.
502460
503461
## Support Procedures
504462

0 commit comments

Comments
 (0)