Skip to content

Commit 07a5d98

Browse files
committed
[MCO-1914] Enhacement of the MCO OS streams feature
This commit adds the formal enhancement proposal for MCO-1914. This feature adds the ability to run multiple OS base images simultaneously in a cluster by allowing users to select an image 'stream' on a per-MCP basis.
1 parent 2586771 commit 07a5d98

File tree

1 file changed

+188
-0
lines changed

1 file changed

+188
-0
lines changed
Lines changed: 188 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,188 @@
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

Comments
 (0)