ephemeral: Add Ignition config injection support#232
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds support for injecting Ignition configuration files into ephemeral VMs. The implementation correctly handles different injection methods for various architectures (fw_cfg for x86_64/aarch64 and virtio-blk for s390x/ppc64le). The changes include updates to QEMU configuration, command-line options, and logic to detect Ignition support in images.
My review includes a couple of suggestions to improve code clarity, reduce duplication, and enhance performance. Specifically, I've recommended refactoring the virtio-blk device addition methods for better maintainability and optimizing the Ignition support check to be more efficient.
gursewak1997
force-pushed
the
add-ignition-support
branch
2 times, most recently
from
e74f5fd to
7be5f96
Compare
cgwalters
left a comment
cgwalters
left a comment
There was a problem hiding this comment.
Thanks for working on this!
I think we really want an integration test for this. Did you test it with the fcos image? I have a suspicion that it may require an ignition.platform.id=qemu karg to be injected too.
And per discussion...some basic docs would be good, I think an example in the man page for ephemeral run is probably enough with a small concrete example?
Also, while starting with ephemeral is fine...we probably want libvirt support too.
(And yeah right now it definitely stinks to have direct qemu for ephemeral vs libvirt)
| )); | ||
| } | ||
|
|
||
| cmd.args([ |
There was a problem hiding this comment.
What might be less cumbersome here is to pass it as an environment variable? Then we don't need to juggle paths across the mount, we just read it in here, and the code inside can just check for the env var.
gursewak1997
force-pushed
the
add-ignition-support
branch
2 times, most recently
from
86e645a to
1b5eebe
Compare
cgwalters
left a comment
cgwalters
left a comment
There was a problem hiding this comment.
Thanks for working on this! I just have mostly nits
crates/kit/src/run_ephemeral.rs
Outdated
|
|
||
| // Check for coreos.ignition label (future convention) | ||
| if let Some(ignition_value) = labels.get("coreos.ignition") { | ||
| if ignition_value == "1" { |
There was a problem hiding this comment.
Hmm actually...what would make a lot of sense is for the image to include the version of ignition in that label. So let's change this to just accept any value for that?
cc @spresti any opinions?
gursewak1997
force-pushed
the
add-ignition-support
branch
2 times, most recently
from
6fa38b5 to
6d48b55
Compare
Add support for injecting Ignition configuration files into ephemeral VMs via QEMU's fw_cfg mechanism (x86_64/aarch64) and virtio-blk (s390x/ppc64le). This enables first-boot provisioning for bootc-based systems that use Ignition. Assisted-by: Claude Code (Sonnet 4.5) Signed-off-by: gursewak1997 <gursmangat@gmail.com>
gursewak1997
force-pushed
the
add-ignition-support
branch
from
6d48b55 to
1ac8a32
Compare
2 participants
Add support for injecting Ignition configuration files into ephemeral
VMs via QEMU's fw_cfg mechanism (x86_64/aarch64) and virtio-blk
(s390x/ppc64le). This enables first-boot provisioning for bootc-based
systems that use Ignition.
Implementation:
Testing:
Documentation:
The config is successfully passed to the guest (verified via
/sys/firmware/qemu_fw_cfg/ and /proc/cmdline). Ignition will process
it on first boot. For ephemeral testing with pre-built FCOS images,
Ignition skips as expected (subsequent boot behavior).
Useful for custom bootc images with Ignition (see bootc initramfs
docs) and future to-disk workflows.