Simplify qcow2 directory structure

[lzap]

Instead of having unique directory for each verison-arch let's only have this for each individual arch until we need this. This is much more readable and this is what I do also in the other PR: #36

The idea is to have one common directory qcow2 for all files that are the same for all versions and arches, then qcow2-ARCH (podman-style architecture naming) for each arch and then, only when we need it, qcow2-VERSION for specific versions. Note the same directory prefix to keep everything nicely sorted.

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

I already added commented out containerfile instructions for the common directory because we will likely use it, but there is no such file right now but I hear voices that we should probably include cloud-init and I would like to propose adding tuned as well. The other version-based directories can be added once we need them and only for those containerfiles which are relevant.

[ochosi]

Take my feedback with a bag of salt, since I'm not actively contributing to bootc-foundry and images.

Personally, I would focus on aligning the structure of the images repository and this one, since we're essentially defining the same thing twice - once as yaml for rpm-based disk images and once as Containerfile for image mode.
Since images pre-exists, I would look to it for inspiration.

For instance, we could treat images distro.name as the canonical string for cross-repo vocabulary. I know that the container-tags are currently slightly different, but that could be handled in Tekton.

For the directories, this could result in something like targets/<canonical-distro>/qcow2/Containerfile.

Anyway, you catch my drift.
</my2cents>

[lzap]

This PR actually moves away from what you recommend. The main reason is the Azure implementation which shows that 99% of all files are common across distros and versions for the particular image type. This means that we would have to maintain copies of all files across many directories, or use symlinks, hardlinks or some kind of a script or Makefile that syncs them together. It was a mess already and we haven't even started yet.

This allows a simple hierarchy on multiple levels:

• common stuff for given image type
• common stuff for given distro
• common stuff for given version
• common stuff for given arch

Going forward, I would like to take a look on building a CLI utility called osbuild-sysprep that will read a YAML definition and perform all the work done currently by the Containerfile in one step so it could be used this way. Such YAML definition could be then maybe moved into images.

ARG TARGETARCH
ARG DISTRO
ARG VERSION
ARG TYPE

RUN osbuild-sysprep --arch $TARGETARCH --distro $DISTRO --version $VERSION --type $TYPE

There is no need to install this on the image, this could be a multi-stage build. But long-term, I think we should be thinking about moving all of this into the base images properly as RPM package. Pseudo-code:

# Define global arguments that can be used across stages
ARG TARGETARCH
ARG DISTRO
ARG VERSION
ARG TYPE

# --- Stage 1: Build/Preparation ---
FROM quay.io/centos-bootc/centos-bootc:stream10 AS builder

# Re-declare ARGs inside this stage to make them available
ARG TARGETARCH
ARG DISTRO
ARG VERSION
ARG TYPE

# Create the working directory and copy the tool
WORKDIR /var/lib/osbuild/sysprep
COPY ./cmd/osbuild-sysprep /usr/local/bin/

# Execute the utility to prepare the file tree
RUN osbuild-sysprep \
    --arch "${TARGETARCH}" \
    --distro "${DISTRO}" \
    --version "${VERSION}" \
    --type "${TYPE}"

# --- Stage 2: Final Image ---
FROM quay.io/centos-bootc/centos-bootc:stream10

# Copy the prepared tree from the builder stage
# This copies the contents of the folder into the root of the final image
COPY --from=builder /var/lib/osbuild/sysprep/ /

# The final image remains clean of any build-time dependencies

[supakeen]

Please don't introduce another project; there's no reason this can't be a subcommand on image-builder.

[lzap]

Please don't introduce another project; there's no reason this can't be a subcommand on image-builder.

Let's stick with UNIX philosophy please okay.

[thozza]

The main reason is the Azure implementation which shows that 99% of all files are common across distros and versions for the particular image type.

While for a given config file, this may be true, it is not true for all config files for the same image type across different versions.

[lzap]

I am not sure what we are discussing here, this is a trivial improvement. What we have in main are copies of the same file spread across various directories, there is even a typo because I failed to edit all copies of the same file when doing a simple change.

This patch structures files so there are no useless copies, while there are other ways of doing it (symlinks, templating) I think this is the most simple approach, at least for the initial version.

I think that trying to mirror or map what we have in YAML definition is not the right direction we should be taking. If you have ideas, let's discuss them properly somewhere else.

[lzap]

While for a given config file, this may be true, it is not true for all config files for the same image type across different versions.

I do not propose to put everything into a single directory, I thought it is obvious from the diff but let me explain better.

For Azure and this PR what I am doing is multi-tier directories:

• qcow2 - common for the image type
• qcow2-ARCH - arch-specific
• qcow2-VERSION - version-specific

Then in the Container file I do something like:

# Copy ONLY common configuration
COPY qcow2/etc/ /etc/
COPY qcow2/usr/ /usr/

# Copy ONLY architecture-specific configuration
COPY qcow2-${TARGETARCH}/usr/ /usr/

# Copy ONLY version-specific configuration
COPY qcow2-${VERSION}/usr/ /usr/

The premise is that a file is exactly once in one of the tier. This means there are no extra copies.

[thozza]

I think that it is pointless to try to optimize the structure at this point, but I'll approve to get this off my plate.