You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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`
81
84
82
85
### API Extensions
83
86
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.
99
88
100
89
#### Installer
101
90
@@ -458,47 +447,16 @@ Upgrade expectations:
458
447
Downgrade expectations:
459
448
460
449
- 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.
462
451
463
452
## Version Skew Strategy
464
453
465
454
N/A
466
455
467
456
## Operational Aspects of API Extensions
468
457
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
- 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.
0 commit comments