osbuild: add support for metal platform #3654
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Merged
dustymabe
force-pushed
the
dusty-osbuild-metal
branch
2 times, most recently
from
5af5bb4 to
48c7195
Compare
Bumping to v99 lets us drop 0001-objectstore-also-mount-etc-containers-for-host-build.patch. We'll also include the yet to be released 0001-stages-add-kernel-cmdline.bls-append-stage.patch and also a 0001-osbuild-util-fscache-calculate-actual-size-of-files.patch to fix how the osbuild cache file sizes are calcuated.
This reworks the coreos.osbuild.mpp.yaml to use the new kernel-cmdline.bls-append
stage [1], enabling us to share earlier stages among the platform specific pipelines.
We have renamed the pipeline stages to be more appropriate. Now we have
- tree
- the filesystem tree
- raw-image
- builds on "tree"
- a raw disk image with nothing platform specific, like kernel arguments
- raw-metal-image
- builds on "raw-image"
- adds kernel arguments specific to `metal` platform
- raw-qemu-image
- builds on "raw-image"
- adds kernel arguments specific to `qemu` platform
- metal
- builds on "raw-metal-image"
- copies out raw image file from "raw-metal-image" stage
- no other modifications needed
- qemu
- builds on "raw-qemu-image"
- converts raw image file from "raw-qemu-image" into a qcow2
We have also modified cmd-buildextend-metal to support calling
runvm-osbuild for either metal or qemu platform images and also added
support for running with the cache qcow2. The cache qcow will allow us
to call osbuild multiple times, with later invocations building on work
done in previous invocations. For example if we checkpiont the `tree`
and `raw-image` stages (as depicted above) then when we call osbuild to
build the `metal` image it won't have to do the work for that. The
benefits of this will compound when we start to build more disk images
in this way.
[1] osbuild/osbuild#1429
jlebon
force-pushed
the
dusty-osbuild-metal
branch
from
48c7195 to
cb8abcc
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This reworks the coreos.osbuild.mpp.yaml to use the new kernel-cmdline.bls-append
stage [1], enabling us to share earlier stages among the platform specific pipelines.
We have renamed the pipeline stages to be more appropriate. Now we have
metalplatformqemuplatformWe have also modified cmd-buildextend-metal to support calling
runvm-osbuild for either metal or qemu platform images and also added
support for running with the cache qcow2. The cache qcow will allow us
to call osbuild multiple times, with later invocations building on work
done in previous invocations. For example if we checkpiont the
treeand
raw-imagestages (as depicted above) then when we call osbuild tobuild the
metalimage it won't have to do the work for that. Thebenefits of this will compound when we start to build more disk images
in this way.
[1] osbuild/osbuild#1429