Skip to content

Commit 8e97011

Browse files
authored
Merge pull request #93065 from mburke5678/mco-boot-image-opt-out
Opt-out updated bootimage for GCP and AWS
2 parents c8bf477 + 46a7a81 commit 8e97011

10 files changed

+281
-268
lines changed

_topic_maps/_topic_map.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2820,6 +2820,8 @@ Topics:
28202820
File: nodes-remediating-fencing-maintaining-rhwa
28212821
- Name: Understanding node rebooting
28222822
File: nodes-nodes-rebooting
2823+
- Name: Updated boot images
2824+
File: nodes-update-boot-images
28232825
- Name: Freeing node resources using garbage collection
28242826
File: nodes-nodes-garbage-collection
28252827
- Name: Allocating resources for nodes
Lines changed: 4 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -1,60 +1,13 @@
11
:_mod-docs-content-type: ASSEMBLY
22
:context: machine-configs-configure
3+
include::_attributes/common-attributes.adoc[]
34
[id="mco-update-boot-images"]
45
= Updated boot images
5-
include::_attributes/common-attributes.adoc[]
66

77
toc::[]
88

9-
The Machine Config Operator (MCO) uses a boot image to start a {op-system-first} node. By default, {product-title} does not manage the boot image.
10-
11-
This means that the boot image in your cluster is not updated along with your cluster. For example, if your cluster was originally created with {product-title} 4.12, the boot image that the cluster uses to create nodes is the same 4.12 version, even if your cluster is at a later version. If the cluster is later upgraded to 4.13 or later, new nodes continue to scale with the same 4.12 image.
12-
13-
This process could cause the following issues:
14-
15-
* Extra time to start nodes
16-
* Certificate expiration issues
17-
* Version skew issues
18-
19-
To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) and Amazon Web Services (AWS) clusters. It is not supported for clusters managed by the {cluster-capi-operator}.
20-
21-
If you are not using the default user data secret, named `worker-user-data`, in your machine set, or you have modified the `worker-user-data` secret, you should not use managed boot image updates. This is because the Machine Config Operator (MCO) updates the machine set to use a managed version of the secret. By using the managed boot images feature, you are giving up the capability to customize the secret stored in the machine set object.
22-
23-
To view the current boot image used in your cluster, examine a machine set:
24-
25-
.Example machine set with the boot image reference
26-
27-
[source,yaml]
28-
----
29-
apiVersion: machine.openshift.io/v1beta1
30-
kind: MachineSet
31-
metadata:
32-
name: ci-ln-hmy310k-72292-5f87z-worker-a
33-
namespace: openshift-machine-api
34-
spec:
35-
# ...
36-
template:
37-
# ...
38-
spec:
39-
# ...
40-
providerSpec:
41-
# ...
42-
value:
43-
disks:
44-
- autoDelete: true
45-
boot: true
46-
image: projects/rhcos-cloud/global/images/rhcos-412-85-202203181601-0-gcp-x86-64 <1>
47-
# ...
48-
----
49-
<1> This boot image is the same as the originally-installed {product-title} version, in this example {product-title} 4.12, regardless of the current version of the cluster. The way that the boot image is represented in the machine set depends on the platform, as the structure of the `providerSpec` field differs from platform to platform.
50-
51-
If you configure your cluster to update your boot images, the boot image referenced in your machine sets matches the current version of the cluster.
52-
53-
include::modules/mco-update-boot-images-configuring.adoc[leveloffset=+1]
54-
55-
[role="_additional-resources"]
56-
.Additional resources
57-
58-
* xref:../nodes/clusters/nodes-cluster-enabling-features.adoc#nodes-cluster-enabling[Enabling features using feature gates]
9+
include::snippets/mco-update-boot-images-intro.adoc[]
5910

11+
include::modules/mco-update-boot-images-about.adoc[leveloffset=+1]
6012
include::modules/mco-update-boot-images-disable.adoc[leveloffset=+1]
13+
include::modules/mco-update-boot-images-configuring.adoc[leveloffset=+1]
Lines changed: 83 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,83 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * nodes/nodes/nodes-update-boot-images.adoc
4+
// * machine_configuration/mco-update-boot-images.adoc
5+
6+
:_mod-docs-content-type: PROCEDURE
7+
[id="mco-update-boot-images_{context}"]
8+
= About updated boot images
9+
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+
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.
13+
14+
However, using an older boot image could cause the following issues:
15+
16+
* Extra time to start nodes
17+
* Certificate expiration issues
18+
* Version skew issues
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".
21+
22+
[NOTE]
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}.
25+
====
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:
28+
29+
* If you disable the behavior before updating to a new {product-title} version:
30+
** The boot image version used by the machine sets remains the same {product-title} version as when the feature was disabled.
31+
** When you scale up nodes, the new nodes use that same {product-title} version.
32+
33+
* If you disable the behavior after updating to a new {product-title} version:
34+
** The boot image version used by the machine sets is updated to match the updated {product-title} version.
35+
** When you scale up nodes, the new nodes use the updated {product-title} version.
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+
38+
* If you enable the behavior after disabling:
39+
** The boot image version used by the machine sets is updated to the current {product-title} version, if different.
40+
** When you scale up nodes, the new nodes use the current {product-title} version in the cluster.
41+
42+
[NOTE]
43+
====
44+
Because a boot image is used only when a node is scaled up, this feature has no effect on existing nodes.
45+
====
46+
47+
To view the current boot image used in your cluster, examine a machine set:
48+
49+
.Example machine set with the boot image reference
50+
51+
[source,yaml]
52+
----
53+
apiVersion: machine.openshift.io/v1beta1
54+
kind: MachineSet
55+
metadata:
56+
name: ci-ln-hmy310k-72292-5f87z-worker-a
57+
namespace: openshift-machine-api
58+
spec:
59+
# ...
60+
template:
61+
# ...
62+
spec:
63+
# ...
64+
providerSpec:
65+
# ...
66+
value:
67+
disks:
68+
- autoDelete: true
69+
boot: true
70+
image: projects/rhcos-cloud/global/images/rhcos-412-85-202203181601-0-gcp-x86-64 <1>
71+
# ...
72+
----
73+
<1> This boot image is the same as the originally-installed {product-title} version, in this example {product-title} 4.12, regardless of the current version of the cluster. The way that the boot image is represented in the machine set depends on the platform, as the structure of the `providerSpec` field differs from platform to platform.
74+
75+
// The following admonition is intended to address https://issues.redhat.com/browse//OSDOCS-14592
76+
[IMPORTANT]
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:
79+
80+
. Disable updated boot images. For more information, see "Disabling updated boot images".
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".
83+
====

modules/mco-update-boot-images-configuring.adoc

Lines changed: 27 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -1,26 +1,28 @@
11
// Module included in the following assemblies:
22
//
33
// * machine-configuration/mco-update-boot-images.adoc
4-
// * nodes/nodes-nodes-managing.adoc
4+
// * nodes/nodes/nodes-update-boot-images.adoc
55

66
:_mod-docs-content-type: PROCEDURE
77
[id="mco-update-boot-images-configuring_{context}"]
8-
= Configuring updated boot images
8+
= Enabling updated boot images
99

10-
By default, {product-title} does not manage the boot image. You can configure your cluster to update the boot image whenever you update your cluster by modifying the `MachineConfiguration` object.
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.
1111

12-
Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) and Amazon Web Services (AWS) clusters. It is not supported for clusters managed by the {cluster-capi-operator}.
12+
If you disabled this default behavior, so that the boot images are not updated, you can revert to the default behavior by editing the `MachineConfiguration` object.
13+
14+
Enabling the default behavior updates the boot image to the current {product-title} version. If the cluster is again updated to a new {product-title} version in the future, the boot image is updated again. New nodes created after enabling the feature use the updated boot image. This feature has no effect on existing nodes.
1315

1416
.Procedure
1517

16-
. Edit the `MachineConfiguration` object, named `cluster`, to enable the updating of boot images by running the following command:
18+
. Edit the `MachineConfiguration` object, named `cluster`, to enable the default boot image update behavior for some or all of your machine sets:
1719
+
1820
[source,terminal]
1921
----
2022
$ oc edit MachineConfiguration cluster
2123
----
2224

23-
* Optional: Configure the boot image update feature for all the machine sets:
25+
* Optional: Enable the default behavior for all machine sets:
2426
+
2527
[source,yaml]
2628
----
@@ -33,15 +35,17 @@ spec:
3335
# ...
3436
managedBootImages: <1>
3537
machineManagers:
36-
- resource: machinesets
37-
apiGroup: machine.openshift.io
38+
- apiGroup: machine.openshift.io <2>
39+
resource: machinesets <3>
3840
selection:
39-
mode: All <2>
41+
mode: All <4>
4042
----
41-
<1> Activates the boot image update feature.
42-
<2> Specifies that all the machine sets in the cluster are to be updated.
43+
<1> Configures the boot image update feature.
44+
<2> Specifies the API group. This must be `machine.openshift.io`.
45+
<3> Specifies the resource within the specified API group to apply the change. This must be `machinesets`.
46+
<4> Specifies that the default behavior is enabled for all machine sets in the cluster.
4347
44-
* Optional: Configure the boot image update feature for specific machine sets:
48+
* Optional: Enable the default behavior for specific machine sets:
4549
+
4650
[source,yaml]
4751
----
@@ -54,62 +58,34 @@ spec:
5458
# ...
5559
managedBootImages: <1>
5660
machineManagers:
57-
- resource: machinesets
58-
apiGroup: machine.openshift.io
61+
- apiGroup: machine.openshift.io <2>
62+
resource: machinesets <3>
5963
selection:
60-
mode: Partial
64+
mode: Partial <4>
6165
partial:
6266
machineResourceSelector:
6367
matchLabels:
64-
update-boot-image: "true" <2>
68+
region: "east"
6569
----
66-
<1> Activates the boot image update feature.
67-
<2> Specifies that any machine set with this label is to be updated.
70+
<1> Configures the boot image update feature.
71+
<2> Specifies the API group. This must be `machine.openshift.io`.
72+
<3> Specifies the resource within the specified API group to apply the change. This must be `machinesets`.
73+
<4> Specifies that the default behavior is enabled for machine sets with the specified label.
6874
+
6975
[TIP]
7076
====
7177
If an appropriate label is not present on the machine set, add a key-value pair by running a command similar to following:
7278
7379
----
74-
$ oc label machineset.machine ci-ln-hmy310k-72292-5f87z-worker-a update-boot-image=true -n openshift-machine-api
80+
$ oc label machineset.machine ci-ln-hmy310k-72292-5f87z-worker-a region: "east" -n openshift-machine-api
7581
----
7682
====
7783
7884
.Verification
7985
80-
. View the current state of the boot image updates by viewing the machine configuration object:
81-
+
82-
[source,terminal]
83-
----
84-
$ oc get machineconfiguration cluster -n openshift-machine-api -o yaml
85-
----
86-
+
87-
.Example machine set with the boot image reference
88-
+
89-
[source,yaml]
90-
----
91-
kind: MachineConfiguration
92-
metadata:
93-
name: cluster
94-
# ...
95-
status:
96-
conditions:
97-
- lastTransitionTime: "2024-09-09T13:51:37Z" <1>
98-
message: Reconciled 1 of 2 MAPI MachineSets | Reconciled 0 of 0 CAPI MachineSets
99-
| Reconciled 0 of 0 CAPI MachineDeployments
100-
reason: BootImageUpdateConfigurationAdded
101-
status: "True"
102-
type: BootImageUpdateProgressing
103-
- lastTransitionTime: "2024-09-09T13:51:37Z" <2>
104-
message: 0 Degraded MAPI MachineSets | 0 Degraded CAPI MachineSets | 0 CAPI MachineDeployments
105-
reason: BootImageUpdateConfigurationAdded
106-
status: "False"
107-
type: BootImageUpdateDegraded
108-
----
109-
<1> Status of the boot image update. {cluster-capi-operator} machine sets and machine deployments are not currently supported for boot image updates.
110-
<2> Indicates if any boot image updates failed. If any of the updates fail, the Machine Config Operator is degraded. In this case, manual intervention might be required.
86+
include::snippets/mco-update-boot-images-verification.adoc[]
11187
112-
. Get the boot image version by running the following command:
88+
* Get the boot image version by running the following command:
11389
+
11490
[source,terminal]
11591
----

0 commit comments

Comments
 (0)