|
5 | 5 |
|
6 | 6 | :_mod-docs-content-type: PROCEDURE
|
7 | 7 | [id="mco-update-boot-images_{context}"]
|
8 |
| -= About updated boot images |
| 8 | += About boot image management |
9 | 9 |
|
10 | 10 | By default, for {gcp-first} and {aws-first} clusters, the Machine Config Operator (MCO) updates the boot image in the machine sets in your cluster whenever you update your cluster.
|
11 | 11 |
|
12 |
| -For {gcp-short} and {aws-short}, you can disable this default behavior, if needed. When disabled, the boot image no longer updates with the cluster. For example, with the default behavior disabled, if your cluster was originally created with {product-title} 4.16, the boot image that the MCO would use to create nodes is the same 4.16 version, even if your cluster is at a later version. |
| 12 | +For {gcp-short} and {aws-short}, you can disable the boot image management feature, if needed. When the feature is disabled, the boot image no longer updates with the cluster. For example, with the feature disabled, if your cluster was originally created with {product-title} 4.16, the boot image that the MCO would use to create nodes is the same 4.16 version, even if your cluster is at a later version. |
13 | 13 |
|
14 | 14 | However, using an older boot image could cause the following issues:
|
15 | 15 |
|
16 | 16 | * Extra time to start nodes
|
17 | 17 | * Certificate expiration issues
|
18 | 18 | * Version skew issues
|
19 | 19 |
|
20 |
| -For information on how to disable the default behavior, see "Disabling updated boot images". If you disable the default behavior, you can enable the default behavior at any time. For more information, see "Enabling updated boot images". |
| 20 | +For information on how to disable this feature, see "Disabling boot image management". If you disable this feature, you can re-enable the feature at any time. For information, see "Enabling boot image management". |
21 | 21 |
|
22 | 22 | [NOTE]
|
23 | 23 | ====
|
24 |
| -The ability to configure this behavior is available for only {gcp-short} and {aws-short} clusters. It is not supported for clusters managed by the {cluster-capi-operator}. |
| 24 | +The ability to configure boot image management is available for only {gcp-short} and {aws-short} clusters. It is not supported for clusters managed by the {cluster-capi-operator}. |
25 | 25 | ====
|
26 | 26 |
|
27 |
| -How the cluster behaves after disabling or re-enabling the default behavior, depends upon when you made the change, including the following scenarios: |
| 27 | +How the cluster behaves after disabling or re-enabling the feature, depends upon when you made the change, including the following scenarios: |
28 | 28 |
|
29 |
| -* If you disable the behavior before updating to a new {product-title} version: |
| 29 | +* If you disable the feature before updating to a new {product-title} version: |
30 | 30 | ** The boot image version used by the machine sets remains the same {product-title} version as when the feature was disabled.
|
31 | 31 | ** When you scale up nodes, the new nodes use that same {product-title} version.
|
32 | 32 |
|
33 |
| -* If you disable the behavior after updating to a new {product-title} version: |
| 33 | +* If you disable the feature after updating to a new {product-title} version: |
34 | 34 | ** The boot image version used by the machine sets is updated to match the updated {product-title} version.
|
35 | 35 | ** When you scale up nodes, the new nodes use the updated {product-title} version.
|
36 | 36 | ** If you update to a later {product-title} version, the boot image version in the machine sets remains at the current version and is not updated with the cluster.
|
37 | 37 |
|
38 |
| -* If you enable the behavior after disabling: |
| 38 | +* If you enable the feature after disabling: |
39 | 39 | ** The boot image version used by the machine sets is updated to the current {product-title} version, if different.
|
40 | 40 | ** When you scale up nodes, the new nodes use the current {product-title} version in the cluster.
|
41 | 41 |
|
|
75 | 75 | // The following admonition is intended to address https://issues.redhat.com/browse//OSDOCS-14592
|
76 | 76 | [IMPORTANT]
|
77 | 77 | ====
|
78 |
| -If any of the machine sets for which you want to enable updated boot images uses a `*-user-data` secret that is based on Ignition version 2.2.0, the Machine Config Operator converts the Ignition version to 3.4.0 when you enable updated boot images. {product-title} versions 4.5 and lower use Ignition version 2.2.0. If this conversion fails, the MCO or your cluster could degrade. An error message that includes _err: converting ignition stub failed: failed to parse Ignition config_ is added to the output of the `oc get ClusterOperator machine-config` command. You can use the following general steps to correct the problem: |
| 78 | +If any of the machine sets for which you want to enable boot image management use a `*-user-data` secret that is based on Ignition version 2.2.0, the Machine Config Operator converts the Ignition version to 3.4.0 when you enable the feature. {product-title} versions 4.5 and lower use Ignition version 2.2.0. If this conversion fails, the MCO or your cluster could degrade. An error message that includes _err: converting ignition stub failed: failed to parse Ignition config_ is added to the output of the `oc get ClusterOperator machine-config` command. You can use the following general steps to correct the problem: |
79 | 79 |
|
80 |
| -. Disable updated boot images. For more information, see "Disabling updated boot images". |
| 80 | +. Disable the boot image management feature. For information, see "Disabling boot image management". |
81 | 81 | . Manually update the `*-user-data` secret to use Ignition version to 3.2.0.
|
82 |
| -. Enable updated boot images. For more information, see "Enabling updated boot images". |
| 82 | +. Enable the boot image management feature. For information, see "Enabling boot image management". |
83 | 83 | ====
|
0 commit comments