Note that I had already kind of discussed this a bit with @eseyman at Flock and he was interested in exploring converting to kiwi for as many of Server's images as possible. So this just kind of moves up the timetable a bit. :sweat_smile:

Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=125070099

if that works, we can grab the resulting images, test actually booting them, and run some comparisons against IF-built images to see any differences.

I will note that this does do XFS+LVM like the old image does, but I really don't recommend XFS (or LVM for that matter) for things like this because it's rather storage inefficient and you can't do online resize (shrink and grow) to reconfigure your storage or deploy other storage configurations later.

This is one of the major reasons why Fedora Asahi and Fedora Cloud use Btrfs.

FYI: @dcavalca, @davdunc, @salimma

I will also point out that when using Btrfs, we can shrink the on-disk size of the images by around 30% to 40% because Btrfs transparent compression pays off in a big way for image builds in kiwi.

The LVM is valuable for mocking up STIG1 and STIG2 configurations. If users want to test environments for enterprise restrictions that will follow them into their workloads on virtualized environments, it might be beneficial to have the LVM+XFS since it potentially matches the scripting requirements for hardened enterprise images. If that's not a factor, for the virtual image, consistency is a strong requirement. I'd like to hear more about the demand for consistency prior to modifying the FS even though I do agree that BTRFS is easier and better for typical cloud configurations.

It is possible to do similar configurations on Btrfs though, so I'm not sure that's an argument. Nobody stops you from making multiple toplevel volumes or subvolumes, and in fact Fedora's Btrfs configuration mimics the LVM configuration precisely for this reason.

In any case, this should be ready to go for now even with XFS+LVM.

FTR, the core members of the SIG already decided to move to Kiwi, hoping this would resolve issue #126. I'll bring up the subject at the SIG meeting tomorrow.

Also FTR, we made a conscious decision a long time ago to use XFS+LVM. I've planned to revisit the decision for F42 but I would prefer the question remain standalone. Let's put this part of the discussion aside and focus on the use of Kiwi for now.

Fine with me. :smile:

Updated scratch build link: https://koji.fedoraproject.org/koji/taskinfo?taskID=125070598

has images for x86_64, aarch64, and ppc64le (s390x is blocked on some kinda koji bug we're waiting for the fix for, IIRC). I suggest folks try the images from that scratch build out and see if they seem to work as well as or better than the current IF image in various scenarios. I'll try and do a package diff again when I get time (I did an initial one with an earlier scratch build and the differences were mainly firmware packages, Neal tweaked that for this second scratch build).

oh, the 'Guest-Generic' part of the name is up for debate, I guess, that's the name Neal picked for this initial test run, but it can be changed if desired (right Neal?)

Yes, the naming is more or less consistent with Cloud and ELN, but if you want something else, we can discuss it.

Also FTR, we made a conscious decision a long time ago to use XFS+LVM.

Hi, I was there for this decision way back in the mists of history. The XFS+LVM layout was chosen for Server Edition specifically because that Edition started life as the place to develop for future RHEL releases and Red Hat had made a decision that the preferred default filesystem layout for RHEL would be XFS+LVM. They did a fairly robust analysis of workloads and customer needs that went into that decision. That information is also now a decade out of date, but I believe RHEL 10 at least will still be shipping this layout.

When creating the cloud images, we followed the pattern we had established for bare metal. This, again, is based on decade-old data, so I think revisiting it is probably worthwhile, particularly since we now have Fedora ELN to supplement Server Edition which can make choices to stay closer to RHEL, giving Server Edition a bit more freedom to change if they see fit to do so.

I would really prefer to keep the migration to kiwi separate from a discussion to replace LVM-XFS as default file system for Server. If I follow e.g. Collin Wolters' argumentation some months ago, the arguments in favor of BTRFS for server installations are technically at least ambiguous. And I see it as a nightmare to manage the data of different users and different programs that have nothing in common on a 10 TB disk in one huge file system. In software development, we follow the principle of loose coupling to increase robustness, and when it comes to the file system, we throw everything together in a tightly coupled way?

Another question, do we want to maintain all editions and spins in one big file? I would prefer to keep it as it is, to have separate files for each deliverable, but common includes for common parts.
That would make maintaining much easier.

They're already not in one big file, for Kiwi. We would likely add a server/ under https://pagure.io/fedora-kiwi-descriptions/blob/rawhide/f/teams .

That's what the pull request already does.

https://pagure.io/pungi-fedora/pull-request/1404 does this.