Skip to content

refactor osbuild manifests to reduce definition duplication#4519

Merged
dustymabe merged 7 commits intocoreos:mainfrom
dustymabe:dusty-refactor-osbuild-manifests
Apr 2, 2026
Merged

refactor osbuild manifests to reduce definition duplication#4519
dustymabe merged 7 commits intocoreos:mainfrom
dustymabe:dusty-refactor-osbuild-manifests

Conversation

@dustymabe
Copy link
Copy Markdown
Member

Previously we had a bunch of duplications in the manifests for two reasons:

  1. For vimdiff, since I thought we needed duplicated definitions due to minute differences between the architectures because...
  2. I didn't understand the mpp-if conditional could be used at lower levels rather than just the stage/node level.

AI helped me come to this realization:

mpp-if already works at a lower level than stage/node level. Looking at the implementation, there's nothing restricting it to stages. The _process_format method (line 1317) recursively
walks the entire YAML tree — dicts and lists alike — and evaluates mpp-if anywhere it encounters it as a dict value. Specifically:

  1. In a dict value (lines 1403-1418): For every key in a dict, if the value is an mpp-if node, it evaluates it and either replaces the value with the then/else result, or deletes the
    key entirely if the chosen branch doesn't exist (remove=True on line 1358 when neither then nor else matches).
  2. In a list element (lines 1420-1432): For every element in a list, if it's an mpp-if node, it evaluates it and either replaces the element or removes it from the list (lines 1431-1432)
    .

So you can use mpp-if at the individual key level inside a dict.

The commits in this PR each march towards sharing definitions across architectures. With this we end up with:

 8 files changed, 778 insertions(+), 3137 deletions(-)

The important thing here is that we can be comfortable with such a large change because the changes can be 100% verified by using osbuild-mpp to generate the osbuild json and verify it's exactly the same as before the commits in this PR.

I've done this already for x86_64 and will do so for the other architectures if people think this PR looks good.

This change was applied to the other multi-arch manifests in
e191262 but I forgot about riscv.
Into their own file named build.common.ipp.yaml. The defnitions here
were exact/verbatim across all architectures.
The ostree.deploy.container stage duplicated the entire stage definition
in both the then/else branches of the mpp-if for ociarchive vs
container-storage, even though only the inputs.images block differs
between the two. Move the mpp-if down to just the inputs.images value
so the stage type, options (osname, target_imgref, mounts, kernel_opts)
are defined once.

This eliminates ~100 lines of duplication across the five architecture
manifests and removes the risk of the options drifting between the
then/else branches.

Written-by: <anthropic/claude-opus-4.6>
Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the osbuild manifests by consolidating redundant pipeline definitions into shared include files: build.common.ipp.yaml, build.raw-image.ipp.yaml, and build.raw-4k-image.ipp.yaml. Architecture-specific manifests for aarch64, ppc64le, riscv64, s390x, and x86_64 have been updated to import these common pipelines, using conditional logic to handle platform-specific configurations such as bootloaders, kernel options, and mount points. I have no feedback to provide as the changes correctly centralize the build logic.

…ionals

Add an 'arch' variable to mpp-vars in each architecture manifest and
use fine-grained mpp-if conditionals to express per-architecture
differences inline rather than as separate code paths:

- bls-append-except-default: conditionally included (not on s390x)
- /boot/efi mkdir stage: conditionally included (EFI arches only)
- /boot/efi in deploy mounts: conditionally included (EFI arches only)
- $ignition_firstboot kernel arg: conditionally included (not on s390x)
- chattr immutable:false before aleph: conditionally included (ppc64le, s390x)
- zipl bootloader config: conditionally included (s390x only)

After this change the tree pipeline YAML is identical across all five
architecture manifests, preparing for extraction into a shared file.

Written-by: <anthropic/claude-opus-4.6>
Use fine-grained mpp-if conditionals on the arch variable to express
per-architecture differences inline in the raw-image and raw-4k-image
pipelines:

- mkfs.fat (EFI-SYSTEM): only on EFI arches (x86_64, aarch64, riscv64)
- /boot/efi mountpoint creation: only on EFI arches
- EFI mount entries in copy/bootupd stages: only on EFI arches
- bootupd stage: not on s390x (uses zipl instead)
- bootupd bios option: x86_64 and ppc64le for raw-image, ppc64le only
  for raw-4k-image (x86_64 does not install BIOS bootloader on 4k disks)
- bootupd bios partition (PReP): only on ppc64le

After this change the raw-image and raw-4k-image pipeline YAML is
identical across all five architecture manifests, along with the
tree pipeline unified in the previous commit.

Written-by: <anthropic/claude-opus-4.6>
Now it is the same across all architectures we can move it into
the shared common file.
These definitions are common across all architectures now so we can move
them out of the arch specific top level files and into shared ones. I
put their own files (one for 4k and one not) because diffing between the
two to see the differences that enable 4k is useful.
@jbtrystram
Copy link
Copy Markdown
Member

Neat. But why spend time on this when we'll move to image builder and get rid of all of these?

@dustymabe
Copy link
Copy Markdown
Member Author

dustymabe commented Apr 1, 2026

Neat. But why spend time on this when we'll move to image builder and get rid of all of these?

A few reasons.

@dustymabe
Copy link
Copy Markdown
Member Author

dustymabe commented Apr 1, 2026

I've done this already for x86_64 and will do so for the other architectures if people think this PR looks good.

verified that for all architectures the generated JSON is the same before/after these changes.

This patch helped:

Details
diff --git a/src/runvm-osbuild b/src/runvm-osbuild
index 2688248d8..d4d105ee6 100755
--- a/src/runvm-osbuild
+++ b/src/runvm-osbuild
@@ -103,11 +103,16 @@ orig_outdir=$outdir
 outdir=cache/osbuild/out
 
 processed_json=$(mktemp -t osbuild-XXXX.json)
+myarch=
+
+for myarch in x86_64 aarch64 riscv64 ppc64le s390x; do
+processed_json="./osbuild-mpp-out-${myarch}.json"
+mppyaml="/usr/lib/coreos-assembler/osbuild-manifests/coreos.osbuild.${myarch}.mpp.yaml"
 
 # Run through the preprocessor
 # Note: don't quote the size arguements since they are numbers, not strings
 set -x; osbuild-mpp                                       \
-    -D arch=\""$(arch)"\"                                 \
+    -D arch=\""${myarch}"\"                                 \
     -D artifact_name_prefix=\""${artifact_name_prefix}"\" \
     -D build_version=\""${build_version}"\"               \
     -D ociarchive=\""${ostree_container}"\"               \
@@ -121,6 +126,9 @@ set -x; osbuild-mpp                                       \
     -D rootfs_size_mb="${rootfs_size_mb}"                 \
     "${mppyaml}" "${processed_json}"
 set +x
+done
+
+exit 1
 
 log_disk_usage
 

@dustymabe dustymabe force-pushed the dusty-refactor-osbuild-manifests branch from 3a82d76 to 0515a94 Compare April 1, 2026 23:08
@dustymabe dustymabe enabled auto-merge (rebase) April 2, 2026 04:38
Copy link
Copy Markdown
Member

@jbtrystram jbtrystram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dustymabe dustymabe merged commit e0c665c into coreos:main Apr 2, 2026
5 checks passed
@dustymabe dustymabe deleted the dusty-refactor-osbuild-manifests branch April 2, 2026 12:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants