|
| 1 | +--- |
| 2 | +title: machine-config-os-images-streams |
| 3 | +authors: |
| 4 | + - "@pablintino" |
| 5 | +reviewers: |
| 6 | + - "@yuqi-zhang" |
| 7 | +approvers: |
| 8 | + - "@yuqi-zhang" |
| 9 | +api-approvers: |
| 10 | + - "@JoelSpeed" |
| 11 | +creation-date: 2025-10-24 |
| 12 | +tracking-link: |
| 13 | + - https://issues.redhat.com/browse/MCO-1914 |
| 14 | +see-also: |
| 15 | +replaces: |
| 16 | +superseded-by: |
| 17 | +--- |
| 18 | + |
| 19 | +# MachineConfig OS Images Streams |
| 20 | + |
| 21 | +## Summary |
| 22 | + |
| 23 | +This enhancement allows administrators to easily assign different OS images |
| 24 | +to specific groups of nodes using a simple "stream" identifier. |
| 25 | + |
| 26 | +It introduces a new, optional stream field in theMCP. When this field is set, |
| 27 | +the MCO will provision nodes in that pool using the specific OS image |
| 28 | +associated with that stream name. |
| 29 | + |
| 30 | +This provides a simple, declarative way to run different OS variants within |
| 31 | +the same cluster. This can be used to test new major OS versions |
| 32 | +(like RHEL 10) on a subset of nodes or to deploy specialized images, |
| 33 | +without affecting the rest of the cluster. |
| 34 | + |
| 35 | +## Motivation |
| 36 | + |
| 37 | +**TBD** |
| 38 | + |
| 39 | + |
| 40 | +### User Stories |
| 41 | + |
| 42 | +**TBD** |
| 43 | + |
| 44 | +### Goals |
| 45 | + |
| 46 | +**TBD** |
| 47 | + |
| 48 | +### Non-Goals |
| 49 | + |
| 50 | +**TBD** |
| 51 | + |
| 52 | +## Proposal |
| 53 | + |
| 54 | +To implement the functionality this enhancement provides, some changes are |
| 55 | +required in the MCO, the released images payload, and the CoreOS images. |
| 56 | +The following sections describe all the required changes. |
| 57 | + |
| 58 | +### Machine Config Pools |
| 59 | + |
| 60 | +To provide the user with the ability to set which stream an MCP's nodes |
| 61 | +should use, the MCP CRD must be modified to introduce a few fields: |
| 62 | + |
| 63 | +- `spec.osImageStream`: To set the target stream the pool should use. We |
| 64 | +preserve the current behavior of deploying the cluster-wide OS images if |
| 65 | +no stream is set. |
| 66 | +- `status.osImageStream`: To inform the user of the stream currently used |
| 67 | +by the pool. This field will reflect the target stream once the pool has |
| 68 | +finished updating to it. |
| 69 | + |
| 70 | +The [API Extensions](#api-extensions) section describes these API changes |
| 71 | +in greater detail. |
| 72 | + |
| 73 | +From the perspective of the MCP reconciliation logic, the addition of |
| 74 | +streams is not different from an override of both OS images in the |
| 75 | +MachineConfig of the associated pool. If a user sets a stream in the |
| 76 | +pool, the MCO takes care of picking the proper URLs to use from the |
| 77 | +new, internally populated, OSImageStream resource and injecting them |
| 78 | +as part of the MCP's MachineConfig. This internal change of the URLs |
| 79 | +will force the MCP to update and deploy the image on each node one by |
| 80 | +one. |
| 81 | + |
| 82 | +### CoreOS and Payload Images |
| 83 | + |
| 84 | +The scope of this enhancement is to allow the user to consume streams shipped |
| 85 | +as part of the payload. Therefore, all information about which streams are |
| 86 | +available should be contained in the payload image and the tagged OS images. |
| 87 | + |
| 88 | +To accommodate more than one OS version and the associated stream name, the |
| 89 | +release build process has been updated with the following changes: |
| 90 | + |
| 91 | +The Payload ImageStream now contains extra coreos tags for both OS and |
| 92 | +Extension Images to accommodate more OS versions. |
| 93 | + |
| 94 | +Each OS image is now built with an extra label that allows the MCO to identify |
| 95 | +the stream to which it belongs. |
| 96 | + |
| 97 | +- Regular OS Images: `io.coreos.oscontainerimage.osstream` pointing to the |
| 98 | +stream name, for example, `rhel-coreos-10`. |
| 99 | +- Extension Images: `io.coreos.osextensionscontainerimage.osstream` pointing |
| 100 | +to the stream name, for example, `rhel-coreos-10`. |
| 101 | + |
| 102 | +With those changes to the images in place, the MCO has enough information to |
| 103 | +build the list of available streams and determine which images should be used |
| 104 | +for each stream. |
| 105 | + |
| 106 | +### Machine Config OSImageStream |
| 107 | + |
| 108 | +This new resource holds the URLs associated with each stream and is populated |
| 109 | +by the MCO using the information from the OS image labels. The logic that |
| 110 | +extracts the URLs and stream names from the OS images differs depending on |
| 111 | +whether the cluster is bootstrapping or undergoing an update. During regular |
| 112 | +operation (i.e., when not bootstrapping or updating), the MCO does not make |
| 113 | +any changes to this resource, and its information can be safely considered |
| 114 | +static. |
| 115 | + |
| 116 | +#### TBD: Add details of both OSImageStream generation scenarios |
| 117 | + |
| 118 | +#### Streams |
| 119 | + |
| 120 | +### API Extensions |
| 121 | + |
| 122 | +**TBD** |
| 123 | + |
| 124 | +### Topology Considerations |
| 125 | + |
| 126 | +**TBD** |
| 127 | + |
| 128 | +### Implementation Details/Notes/Constraints |
| 129 | + |
| 130 | +**TBD** |
| 131 | + |
| 132 | +### Risks and Mitigations |
| 133 | + |
| 134 | +**TBD** |
| 135 | + |
| 136 | +### Drawbacks |
| 137 | + |
| 138 | +**TBD** |
| 139 | + |
| 140 | +## Design Details |
| 141 | + |
| 142 | +### Open Questions [optional] |
| 143 | + |
| 144 | +None. |
| 145 | + |
| 146 | +## Test Plan |
| 147 | + |
| 148 | +**TBD** |
| 149 | + |
| 150 | +## Graduation Criteria |
| 151 | + |
| 152 | +**TBD** |
| 153 | + |
| 154 | +### Dev Preview -> Tech Preview |
| 155 | + |
| 156 | +**TBD** |
| 157 | + |
| 158 | +### Tech Preview -> GA |
| 159 | + |
| 160 | +**TBD** |
| 161 | + |
| 162 | +### Removing a deprecated feature |
| 163 | + |
| 164 | +## Upgrade / Downgrade Strategy |
| 165 | + |
| 166 | +**TBD** |
| 167 | + |
| 168 | +## Version Skew Strategy |
| 169 | + |
| 170 | +**TBD** |
| 171 | + |
| 172 | +## Operational Aspects of API Extensions |
| 173 | + |
| 174 | +#### Failure Modes |
| 175 | + |
| 176 | +**TBD** |
| 177 | + |
| 178 | +## Support Procedures |
| 179 | + |
| 180 | +None. |
| 181 | + |
| 182 | +## Implementation History |
| 183 | + |
| 184 | +Not applicable. |
| 185 | + |
| 186 | +## Alternatives (Not Implemented) |
| 187 | + |
| 188 | +**TBD** |
0 commit comments