What we are asking
This is a community clarification question about how the MCO tracks Ignition config spec
versions. For the concrete "OCP 4.22 MCO rejects a 3.6.0 MachineConfig" symptom, see
coreos/butane#715 for reference. We would appreciate the maintainers' confirmation on the
points below.
Background
To keep the questions concrete, here is what we have already confirmed from primary sources and on a
live cluster. Please correct anything inaccurate.
- The MCO
release-4.22 (and main) requires github.com/coreos/ignition/v2 v2.20.0 and, in
pkg/controller/common/helpers.go, imports config/v3_5 (no config/v3_6). It parses incoming
configs via ign3.ParseCompatibleVersion(...).
- On a live OCP 4.22 cluster,
go version -m on the MCO binary reports
dep github.com/coreos/ignition/v2 v2.20.0.
- Stable Ignition config spec
3.6.0 first exists in the Ignition library v2.26.0 (2026-02-17);
spec 3.5.0 has existed since v2.20.0 (2024-10-22).
- Upstream Butane
v0.28.0 (2026-05-19) stabilized the openshift 4.22.0 variant to emit
ignition.version: 3.6.0; openshift 4.21.0 (and earlier) emit 3.5.0.
- We read this to mean the OCP 4.22 MCO's accepted-input and rendered-output Ignition spec
ceiling is 3.5.0, while the matching Butane variant now produces 3.6.0.
Throughout, we deliberately distinguish three separate "versions" to avoid ambiguity:
- (A) the Ignition config spec version (
3.5.0, 3.6.0) — the on-disk MachineConfig format;
- (B) the Ignition Go library + parser package the MCO vendors (
coreos/ignition/v2 +
config/v3_N) — this is what sets the MCO's spec ceiling;
- (C) the Ignition binary/utility shipped in RHCOS that consumes the config at firstboot.
Questions
-
Confirm current state. Is it correct that the OCP 4.22 MCO accepts and renders Ignition
config spec only up to 3.5.0 (because it vendors coreos/ignition/v2 v2.20.0 and imports
config/v3_5), so a MachineConfig declaring stable ignition.version: 3.6.0 is rejected at
render time?
-
Version-tracking policy. Butane's
latest openshift variant tracks the latest spec (3.6.0). Does the MCO intend to track the
Ignition library/parser (B) up to the level shipped in its own release or is staying on v2.20.0 /
config/v3_5 for 4.22
intentional? What policy decides when the MCO's config/v3_N import is bumped?
-
z-stream behavior. Could the accepted/rendered Ignition spec ceiling be
raised to 3.6.0 within a 4.22.z (patch / z-stream) update or would a config/v3_6 bump only ship in a later minor (4.23+)? Is
raising the spec ceiling within a z-stream considered supported at all?
-
Backward compatibility (ParseCompatibleVersion). If/when the MCO moves to
config/v3_6, our understanding is that config/v3_6.ParseCompatibleVersion accepts any known
v3 spec up to and including 3.6.0 and converts it to the v3_6 internal type — so a 3.5.0
MachineConfig generated by Butane
openshift 4.21.0 would continue to be accepted. Is that correct — i.e. a config/v3_6 MCO
would not break existing 3.5.0 MachineConfigs?
-
Butane ↔ MCO coordination. Where is the cross-release synchronization between the Butane
openshift variant → Ignition spec mapping and the MCO's supported spec ceiling guaranteed (or
is it not)? Historically the Butane side was rolled back when the MCO lagged
(coreos/butane#312).
Why this matters
Following the documented workflow (set the Butane openshift version: to match the cluster, i.e.
4.22.0) currently yields a 3.6.0 MachineConfig that the 4.22 MCO rejects, degrading the target
MachineConfigPool. Clear answers to the above would make it clear how to address this.
Related
coreos/butane issue (roll back the openshift 4.22.0 variant to 3.5.0, per the
coreos/butane#312 precedent): coreos/butane#715
- Prior Butane policy / precedents:
coreos/butane#312 (standing policy),
coreos/butane#269 / coreos/butane#307 (prior rollbacks for openshift 4.9 / 4.10).
- MCO PR
openshift/machine-config-operator#4903 (MCO-1579 — last Ignition bump, to 3.5; OCP 4.19).
Environment
- OpenShift Container Platform: stable-4.22
- MCO vendored Ignition:
github.com/coreos/ignition/v2 v2.20.0 (confirmed via go version -m)
- Butane:
0.28.0
What we are asking
This is a community clarification question about how the MCO tracks Ignition config spec
versions. For the concrete "OCP 4.22 MCO rejects a
3.6.0MachineConfig" symptom, seecoreos/butane#715for reference. We would appreciate the maintainers' confirmation on thepoints below.
Background
To keep the questions concrete, here is what we have already confirmed from primary sources and on a
live cluster. Please correct anything inaccurate.
release-4.22(andmain) requiresgithub.com/coreos/ignition/v2 v2.20.0and, inpkg/controller/common/helpers.go, importsconfig/v3_5(noconfig/v3_6). It parses incomingconfigs via
ign3.ParseCompatibleVersion(...).go version -mon the MCO binary reportsdep github.com/coreos/ignition/v2 v2.20.0.3.6.0first exists in the Ignition libraryv2.26.0(2026-02-17);spec
3.5.0has existed sincev2.20.0(2024-10-22).v0.28.0(2026-05-19) stabilized theopenshift 4.22.0variant to emitignition.version: 3.6.0;openshift 4.21.0(and earlier) emit3.5.0.ceiling is 3.5.0, while the matching Butane variant now produces 3.6.0.
Throughout, we deliberately distinguish three separate "versions" to avoid ambiguity:
3.5.0,3.6.0) — the on-disk MachineConfig format;coreos/ignition/v2+config/v3_N) — this is what sets the MCO's spec ceiling;Questions
Confirm current state. Is it correct that the OCP 4.22 MCO accepts and renders Ignition
config spec only up to 3.5.0 (because it vendors
coreos/ignition/v2 v2.20.0and importsconfig/v3_5), so a MachineConfig declaring stableignition.version: 3.6.0is rejected atrender time?
Version-tracking policy. Butane's
latest
openshiftvariant tracks the latest spec (3.6.0). Does the MCO intend to track theIgnition library/parser (B) up to the level shipped in its own release or is staying on
v2.20.0/config/v3_5for 4.22intentional? What policy decides when the MCO's
config/v3_Nimport is bumped?z-stream behavior. Could the accepted/rendered Ignition spec ceiling be
raised to
3.6.0within a 4.22.z (patch / z-stream) update or would aconfig/v3_6bump only ship in a later minor (4.23+)? Israising the spec ceiling within a z-stream considered supported at all?
Backward compatibility (
ParseCompatibleVersion). If/when the MCO moves toconfig/v3_6, our understanding is thatconfig/v3_6.ParseCompatibleVersionaccepts any knownv3 spec up to and including
3.6.0and converts it to thev3_6internal type — so a3.5.0MachineConfig generated by Butane
openshift 4.21.0would continue to be accepted. Is that correct — i.e. aconfig/v3_6MCOwould not break existing
3.5.0MachineConfigs?Butane ↔ MCO coordination. Where is the cross-release synchronization between the Butane
openshiftvariant → Ignition spec mapping and the MCO's supported spec ceiling guaranteed (oris it not)? Historically the Butane side was rolled back when the MCO lagged
(
coreos/butane#312).Why this matters
Following the documented workflow (set the Butane
openshift version:to match the cluster, i.e.4.22.0) currently yields a3.6.0MachineConfig that the 4.22 MCO rejects, degrading the targetMachineConfigPool. Clear answers to the above would make it clear how to address this.
Related
coreos/butaneissue (roll back theopenshift 4.22.0variant to3.5.0, per thecoreos/butane#312precedent):coreos/butane#715coreos/butane#312(standing policy),coreos/butane#269/coreos/butane#307(prior rollbacks for openshift 4.9 / 4.10).openshift/machine-config-operator#4903(MCO-1579 — last Ignition bump, to 3.5; OCP 4.19).Environment
github.com/coreos/ignition/v2 v2.20.0(confirmed viago version -m)0.28.0