Re: Call for GSoC internship project ideas

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
> Hi Marc-André,
> I haven't seen discussion about the project ideas you posted, so I'll
> try to kick it off here for the mkosi idea here.
> 
> Thomas: Would you like to co-mentor the following project with
> Marc-André? Also, do you have any concerns about the project idea from
> the maintainer perspective?
> 
> === Reproducible Test Image Building with mkosi ===

> This project proposes using mkosi to build minimal, reproducible test
> images directly from distribution packages. mkosi is a tool for
> building clean OS images from distribution packages, with excellent
> support for Fedora and other distributions. It should be able to
> produces deterministic outputs.

Aside from what I mentioned already, the other issue I anticipate
with mkosi is the mismatch between what hardware QEMU needs to be
able to cover, vs what hardware the distros actually support.

Fedora in particular is pretty narrow in its coverage. Debian is
considerably broader.

Neither will support all the QEMU targets, let alone all the
machine types within the target.


While there is value in testing a full blown OS image, IMHO,
for most of what we need it is considerable overkill, and
thus makes functional tests slower than they would otherwise
need to be.

IMHO, our baseline for functional testing images ought to be
a Linux Kconfig recipe used to build a dedicate kernel, plus
a busybox build for the target.

This would let us create either a self contained initrd, or
a tiny root disk, both of which would reliably boot in a
barely more than a second or two, even under TCG.

This would have a number of other benefits

 * Not dependent on distros supporting the given QEMU
   target and machine type. As long as a Linux port
   exists and busybox compiles, we can test it
 
 * Identical test image functionality for every single
   target and machine type. No hodge-podge of different
   3rd party guest OS.

 * Stable forever, with all changes entirely under
   our own control. No distro changes that arbitrarily
   break our CI.

 * Easier to debug when it breaks, since there would
   be a small well defined set of logic running in
   the guest userspace

 * Fairly easy for QEMU to provide the complete and
   corresponding source for any binary images, since
   we've built it all from scratch

 * Tiny & fast downloads of pre-built images.


This would not eliminate the need for testing real OS images,
but would significantly downgrade their importance.

Functional tests could be in three groups - 'quick', as today,
'slow' the smoke tests with our miny kernel+busybox, 'thorough'
the full OS images.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|