fedora-qcow2: derived containers

[lzap]

This adds Fedora qcow2 derived containerfile. I wanted to start small, this is the most simple one. This PR is meant for discussion, I am making several assumptions which might be completely wrong.

Image definitions

I used the qcow2 and/or cloud-qcow2 image definitions when writing those Containerfiles as inspiration and my workflow was dropping anything that is not needed or not relevant for bootc.

Assumption: users of the qcow2 image use cockpit-machines, libvirt or qemu/kvm directly. Although it is technically possible to use cloud-init in these environments, users must do additional configuration to achieve that (network endpoint, mount an ISO with seed info). Since image builder can actually help to set up users, passwords and ssh-keys, I am leaving cloud-init out of this.

I reviewed packages from both definitions and came up with the list that includes guest agents group plus some tools that might be required for storage/filesystems.

Dropped packages

Fedora

• "@server-product-environment"
• "@domain-client"
• "glibc-all-langpacks"

EL10

• "@core"
• "chrony"
• "cloud-init"
• "cloud-utils-growpart"
• "cockpit-system"
• "cockpit-ws"
• "dnf-utils"
• "dosfstools"
• "nfs-utils"
• "oddjob"
• "oddjob-mkhomedir"
• "psmisc"
• "python3-jsonschema"
• "qemu-guest-agent"
• "redhat-release"
• "redhat-release-eula"
• "rsync"
• "system-reinstall-bootc"
• "tar"
• "tuned"
• "tcpdump"

EL9

• "@core"
• "authselect-compat"
• "chrony"
• "cloud-init"
• "cloud-utils-growpart"
• "cockpit-system"
• "cockpit-ws"
• "dnf-utils"
• "dosfstools"
• "nfs-utils"
• "oddjob"
• "oddjob-mkhomedir"
• "psmisc"
• "python3-jsonschema"
• "qemu-guest-agent"
• "redhat-release"
• "redhat-release-eula"
• "rsync"
• "tar"
• "tuned"
• "tcpdump"

Kernel command line and bootloader

These image definitions do set up kernel command line with focus on console and serial console. This is very useful in cockpit where console is fully native. Therefore I am including those arguments, but leaving out the speed which is not needed in virtualized environments.

I noticed that in other cloud environments we do also set grub2 kernel command line too. Shall we do that here?

GRUB_TERMINAL="serial console"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

Also, in other images we disable recovery, I did not find this in our distro defs either, so left this out:

GRUB_DISABLE_RECOVERY="true"

Personally, I would love a shorter timeout but I think we should stick with the default value.

GRUB_TIMEOUT=4

Interface naming in EL9

I am not including the kernel command line option net.ifnames=0 for EL9 image.

Git repo organization

Now, few practical things. I am trying to keep as much files as possible out of the containerfile. I noticed that the pattern used in the bootc world is to have a single directory and have the COPY verb to do all the work, it copies recursively by default.

But we will need separate directories per version (when it drifts) and architecture so I created:

fedora-qcow2-amd64
└── usr
    └── lib
        └── bootc
            └── kargs.d
                └── 50-kargs-x86_64.toml
fedora-qcow2-arm64
└── usr
    └── lib
        └── bootc
            └── kargs.d
                └── 50-kargs-aarch64.toml

The verb actually automatically enforces root:root owner, unless specified otherwise via --owner, it also respects permissions but applies umask. Generally speaking, it should work and executable files will be kept.

Testing the images

The image boots fine, serial console works nicely in libvirt, I cannot see or control grub via serial console because that is currently not configured.

Initial setup - DROPPED

But, the initial-setup never disappears until it is confirmed in TUI/GUI. I think it does not make sense to have it in derived containers, users can add it if they want. Therefore I am removing initial-setup.

1) [ ] Language settings                 2) [x] Time settings
       (Language is not set.)                   (America/New_York timezone)
3) [x] Network configuration             4) [!] Root password
       (Connected: enp1s0)                      (Root account is disabled)
5) [!] User creation
       (No user will be created)

RHSM + Lightspeed

Works fine:

+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Not registered

bash-5.2# rhc connect --activation-key xxxx --organization xxxx
Connecting localhost.localdomain to Red Hat.
This might take a few seconds.

Features preferences: [✓]content, [✓]analytics, [✓]remote-management

 [✓] Connected to Red Hat Subscription Management
  [✓] Content ... Red Hat repository file generated
  [✓] Analytics ... Connected to Red Hat Lightspeed (formerly Insights)
  [✓] Remote Management ... Activated the yggdrasil service

Successfully connected to Red Hat!

Manage your connected systems: https://red.ht/connector

tuned - DROPPED

Is disabled by default, recognizes guest automatically:

bash-5.2# tuned-adm active
Current active profile: virtual-guest

[supakeen]

If it works this is fine; we're not purporting to be any specific Fedora variant and it all seems in-line with what I'd expect.

Let's not touch anything grub related to be honest; it shouldn't really be necessary and it should be managed by bootupd (if not now; then eventually?).

[croissanne]

lgtm afaik!

[lzap]

I am currently testing the image, but since this is new and sets the bar for other containerfiles, please give this a read @achilleas-k and @thozza (and anyone interested).

[lzap]

So the initial-setup did not work as I assumed, I thought it disappears after first reboot but this is persistent until user confirms or cancels it in TUI/GUI. I think this is way too much for generic derived bootc images, so I am removing this. Also fixed one typo and elaborated the description.

[lzap]

• Broken down into directories separated by architecture, introduced the standard TARGETARCH variable for that
• Reviewed all packages which are installed and basically dropped 50% of all the lines :-)

Thanks @supakeen and @thozza

[lzap]

Ready for final review. I rebased on top of Konflux pipeline cleanup, we are aiming to do all builds in Konflux. For this reason, the naming convention changed to match Konflux project structure. Please re-read the description I updated it with some findings during my boot testing.

I realized that I installed many packages which were already part of the base image, so container files are now much lighter.

Also, @supakeen raised a concern about tuned so please chip in if you prefer not to ship this at all. Adding it could make it hard for people who would prefer not using it, on the other hand, bootc base image already contains a ton of things.

containerfiles/
├── el10-qcow2-amd64
│   └── usr
│       └── lib
│           └── bootc
│               └── kargs.d
│                   └── 50-kargs-x86_64.toml
├── el10-qcow2-arm64
│   └── usr
│       └── lib
│           └── bootc
│               └── kargs.d
│                   └── 50-kargs-aarch64.toml
├── el9-qcow2-amd64
│   └── usr
│       └── lib
│           └── bootc
│               └── kargs.d
│                   └── 50-kargs-x86_64.toml
├── el9-qcow2-arm64
│   └── usr
│       └── lib
│           └── bootc
│               └── kargs.d
│                   └── 50-kargs-aarch64.toml
├── fedora-qcow2-amd64
│   └── usr
│       └── lib
│           └── bootc
│               └── kargs.d
│                   └── 50-kargs-x86_64.toml
├── fedora-qcow2-arm64
│   └── usr
│       └── lib
│           └── bootc
│               └── kargs.d
│                   └── 50-kargs-aarch64.toml
├── f43-qcow2
├── rhel-10.1-qcow2
├── stream10-qcow2
└── stream9-qcow2

Because the files do not have Containerfile prefix going forward, I added modelines:

# vim: set ft=dockerfile:
# -*- mode: dockerfile-mode -*-
# code: language=dockerfile insertSpaces=true tabSize=4

This is for easier editing, unfortunately .editorconfig does not allow for changing syntax schemes.

[croissanne]

lgtm

[lzap]

One little change, forgot to update COPY Containerfile /root/Containerfile lines, the containerfiles are no longer generated but fully static. The correct line is COPY Containerfile /root/f43-qcow2 etc.

[lzap]

Please re-review I am also moving the file from containerfiles/ to the root since now we build in Konflux things are more simple. @supakeen @thozza

[ondrejbudai]

Looks simple and straightforward, we can always tweak it later as we add more image types and versions.

[thozza]

In general, this looks good, but I have the following comments:

1. The first commit says "move container files", but it just deletes them AFAICT, so the commit message is wrong.
2. I'm not sure where are the kernel args coming from for qcow2, but they don't seem to match our image definitions, which would be desirable.
3. WRT tuned, my position is that it is probably desirable to have it installed by default, but I feel like this should be part of the base bootc container image. My hope that our derived containerfiles will add just the bare minimum to make the system integrate nicely in the target environment, but they do not "finalize" the expected RHEL experience by installing bunch of additional packages. From my PoV, this just adds unwanted maintenance load on us and we should prevent it. Basically say that if tuned should be installed on RHEL image mode qcow2, then it should be in the base container that it is built from.... 🤷

[lzap]

Addressed all @thozza concerns. Reworded the first commit, dropped tuned and fixed kernel command line options.

While we do not set serial console for arm64 in our distrodefs, I think we should since we do this for intel and is quite useful for virtualized environments to have out of box. So I propose to have it here and I can fix that in distrodef too perhaps. We have them for other image types but not for qcow2.

[thozza]

Out of curiosity, and sorry for not following that discussion, how will initial setup work? Is cloud-init part of the base image?

The requested changes were addressed AFAICT.

[lzap]

Out of curiosity, and sorry for not following that discussion, how will initial setup work? Is cloud-init part of the base image?

There is neither cloud-init nor initial-setup, image-builder creates users from a blueprint and users are supposed to boot qcow2 image directly (so no root expansion is needed). Cloud-init would not work in KVM environment anyway unless a network endpoint or seed ISO file is attached.

[thozza]

There is neither cloud-init nor initial-setup, image-builder creates users from a blueprint and users are supposed to boot qcow2 image directly (so no root expansion is needed). Cloud-init would not work in KVM environment anyway unless a network endpoint or seed ISO file is attached.

Well, cloud-init is included by default in our qcow2 package-based images and I consider it part of the platform-specific enablement. By default, we do not require any users to be added to the image as a customization in order to produce a usable image. So my suggestion would be to add it to the qcow2.

[lzap]

Well, cloud-init is included by default in our qcow2 package-based images

The same can be said about tuned which is in my eyes more important to be present than cloud-init which is 9/10 not useful in KVM environment because users need to do extra work in order to leverage it. Yet, we have decided to exclude tuned, which works "out of box" for everyone.

The idea of having those derived containers as thing as possible grew on me and my suggestion is: let's wait until someone asks for cloud-init or initial-setup for qcow2.