Hah, I was having this exact conversation today regarding BZ 2203192.

@davdunc and I realized that fedimg hasn't received updates in quite a while and imagefactory might be in the same situation. I used to work on the team that started osbuild/osbuild-composer and I like their approach especially since the image building and uploading can be done by the same tool. This would take care of our fedimg challenges, too.

@obudai What are we missing in osbuild to make this happen? I know btrfs support is one and the other deals with how dnf marks packages?

KIWI

KIWI is an image build/appliance build tool originally developed by the folks at SUSE. Today, there is a core team of folks in the community that develop and maintain the tooling, which include myself as well as SUSE employees (like @defolos).

Pros

• Supported by SUSE for multiple projects (Open Build Service, Uyuni, etc.)
• Fully supports Btrfs (subvolumes, compression, boot-to-snapshot setup, etc.)
• Supports wider range of image types under our purview:
  • public/private cloud VM images
  • Vagrant boxes
  • WSL images
  • OCI images
• Produces SBOM-ish manifests and image checksums
• Uses a mostly-declarative format for configuring image builds (XML/YAML/JSON + shell script)
• Easy to run locally
• Packaged in Fedora and EPEL
• Builds in Koji are orchestrated and tracked fully in Koji (see example build from CentOS CBS)

Cons

• Declarative portion only supports one level of includes vs kickstart "infinite" include composition
• Originally for SUSE distributions, so terminology and behaviors are different
• SELinux support is somewhat goofy still (though it is being worked on)
• Bootloader Spec support is incomplete

OSBuild

OSBuild is the engine for a pipeline-centric image build system known as OSBuild Composer, which underpins Red Hat's Image Builder service. @obudai has been the primary advocate for this.

Pros

• Supported by Red Hat, underpinning the Cockpit Image Builder app and the hosted Image Builder service
• Supports building cloud disk images
• Uses a declarative format for configuring images (TOML/JSON)
• Possible to run locally
• Packaged in Fedora and RHEL
• Full support for Fedora-style Bootloader Spec bootloader configuration
• Good SELinux support

Cons

• No composition/layering currently supported in the declarative description format
• Btrfs support is incomplete (though subvolume support is in progress)
• No support for some image types (Vagrant boxes, WSL images, OCI images)
• Resulting images don't have a correctly populated DNF database
• OSBuild image builds are opaque, not logged, and non-debuggable (see example build from Fedora IoT)

I think osbuild/osbuild-composer are already building things in koji, so that's something to consider.

Heya!

Ondřej here from the osbuild team. We are happy to collaborate! Regarding cons that Neal mentioned:

Btrfs support is incomplete (though subvolume support is in progress)

I cannot promise anything at this point, but I got basically everything working today:
- https://github.com/osbuild/osbuild/pull/1312
- https://github.com/osbuild/osbuild-composer/pull/3447

If you have any more thoughts, I'm happy to hear them!

No support for some image types (Vagrant boxes, WSL images, OCI images)

OCI (container) images are actually supported. We made some initial work for WSL and Vagrant too. Oracle cloud - we have good experience running just generic qcow2 images there. For bare metal support, see the following PR.

OSBuild image builds are opaque, not logged, and non-debuggable

osbuild currently pushes all the logs and manifests to the relevant task: https://koji.fedoraproject.org/koji/taskinfo?taskID=101288407 This was an oversight and needs to be fixed, see the tracking epic.

Additionally, osbuild has these extra features:

• direct upload to clouds (AWS, Azure, GCP, Oracle). This saves some traffic and speeds up the whole cloud publishing process.
• existing integration with Fedora infra (it is used for building IoT artifacts)
• CLI and a cockpit plugin for simple image building by end users, see https://www.osbuild.org/guides/user-guide/user-guide.html
• integration with Packit: https://packit.dev/docs/configuration/#vm_image_build

I cannot promise anything at this point, but I got basically everything working today:
- https://github.com/osbuild/osbuild/pull/1312
- https://github.com/osbuild/osbuild-composer/pull/3447

woot! definitely looking forward to testing and working with it here.

OCI (container) images are actually supported.
Pretty sure that this was a reference to Oracle Infrastructure support, but this is really important to know!
We made some initial work for WSL and Vagrant too.

We definitely want to keep that on the radar as we are already producing vagrant images and intend to support aarch64 builds for F39.

osbuild currently pushes all the logs and manifests to the relevant task: https://koji.fedoraproject.org/koji/taskinfo?taskID=101288407 This was an oversight . . .

It changes our workflow a little, but it is something we can deal with.

I think that we should effectively look at this as an opportunity to adopt both and track on the osbuild progress in the space we need today. Ultimately, the cockpit integration is a big benefit for our friends who want to use a process that they intend to fold into production.

Kiwi on the other hand supports our migration away from the imgfac tools and away from annoying configuration quirks in our job control today, so I like the idea that we can develop a process that has both models.

I am a firm believer that we should avoid one-way doors, so I think we should do what we can do in osbuild today, but then build the other parts, like vagrant images and WSL using the kiwi tools.

--

• integration with Packit: https://packit.dev/docs/configuration/#vm_image_build

I cannot wait to make this type of configuration work in my own personal build pipeline.

So today, @davdunc and I did a hackfest to make progress on one path of this, and now we have kiwi image descriptions: https://pagure.io/fedora-kiwi-descriptions

This is now implemented for Fedora Linux 40.