refactor(images): compose AZL4 images from hierarchical KIWI profiles

[binujp]

Summary

• add a shared AzureLinux.kiwi entry point for 14 Azure Linux 4 image profiles
• compose images from reusable core, base, repository, boot, security, and leaf profiles
• register existing and proposed images against the shared hierarchy
• centralize shared KIWI hooks and installer payloads at the description root
• remove obsolete standalone image definitions

Validation

• validated the combined description with the KIWI schema parser
• resolved all 14 leaf profiles through KIWI
• compared resolved package sets and core preferences with their source definitions
• validated the image registry, XML structure, scripts, and profile-scoped payloads
• built all eight images shared with the 4.0 branch on both x86_64 and aarch64
• compared normalized filesystem contents, package inventories, OCI runtime configuration, installer ISO contents, and custom installer payloads on both architectures
• confirmed remaining cross-build differences are generated metadata such as timestamps, random IDs, caches, package databases, initramfs output, and content-addressed repository metadata

[Copilot]

Pull request overview

Introduces a shared KIWI hierarchy for Azure Linux 4 image profiles.

Changes:

• Centralizes profile inheritance, configuration, repositories, and packages.
• Registers 22 image profiles against one KIWI entry point.
• Adds hierarchy documentation and an interactive HTML viewer.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
base/images/AzureLinux.kiwi	Adds shared KIWI entry point.
base/images/images.toml	Registers images against shared profiles.
base/images/profiles/profiles.xml	Defines profile inheritance.
base/images/profiles/config.xml	Defines profile-specific image settings.
base/images/profiles/packages.xml	Defines shared package groups.
base/images/README.md	Documents hierarchy composition.
base/images/image-profile-matrix.md	Maps images to profiles.
base/images/profile-package-tables.md	Documents package membership.
base/images/image-hierarchy.html	Adds interactive hierarchy viewer.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 3 comments.

Suppressed comments (2)

base/images/teams/installer.xml:48

• The shared installer package block drops all seven <file> declarations from the existing definition. As a result, the image lacks its network config, Anaconda config/launcher, kickstarts, and post-install scripts; the installer hook also expects /usr/local/bin/anaconda-launcher.sh. Restore these declarations using paths relative to the new shared description directory.

        <package name="vim-minimal" />
    </packages>

base/images/repositories/core.xml:7

• These profiles use PMC beta as their local build-time source, contrary to the registry comment and the established image definitions, which use azl4-dev locally and rely on Koji to override the repository (for example base/images/vm-base/vm-base.kiwi:82-92 and base/images/container-base/container-base.kiwi:110-120). Local 1P/Marketplace builds would therefore consume older published packages rather than the current development set.

    <repository type="rpm-md" alias="azurelinux-base" profiles="1p-vm-base-gen1,1p-vm-base-gen1-fips,1p-vm-base-gen2-fips,marketplace-gen2,marketplace-gen2-cvm,marketplace-gen2-fips">
        <source path="https://packages.microsoft.com/azurelinux/4.0/beta/base/$basearch" />

[Dan Streetman (ddstreetmicrosoft)]

I left several review notes, and stopped before reviewing all of it since I think I'll need to re-review after some changes.

In addition to the review notes, I'm not clear on the specific image types getting built. It seems like you are creating marketplace images only for gen2? And then creating 1p images only for gen1? But that's not at all correct, both 1p and 3p images should be available for gen1 and gen2, unless I am completely misunderstanding things?

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 2 comments.

Suppressed comments (5)

base/images/AzureLinux.kiwi:17

• Because this shared file is now the primary KIWI description, KIWI only auto-discovers sidecar hooks beside base/images/AzureLinux.kiwi. The existing hooks remain at container-base/config.sh and vm-iso-installer/config.sh; XML includes do not import them. Consequently the distroless profiles no longer strip the package manager/RPM database, and the installer no longer creates its offline repository or kickstarts. Add a root hook that dispatches these profile-specific steps (or retain family entry points).

    <include from="this://./teams/installer.xml" />
    <include from="this://./teams/wsl.xml" />
    <include from="this://./teams/container.xml" />

base/images/teams/installer.xml:22

• This relative template is now resolved from the shared description directory (base/images), but the file exists only at base/images/vm-iso-installer/grub_template.cfg. Point to that location so the installer build can load its GRUB template.

            <bootloader name="grub2" timeout="5" grub_template="grub_template.cfg" />

base/images/images.toml:7

• The registry rewrite removes the vm-base-dev, container-base-dev, wsl-dev, and vm-iso-installer-dev images without updating consumers. In particular, scripts/build-vm-images.sh:12 and scripts/demo-build.sh:27 still invoke removed names, and this also eliminates the supported way to produce images carrying azurelinux-repos-dev. Retain equivalent dev leaf profiles/entries or update those workflows deliberately.

# Every image selects one leaf profile from the shared AzureLinux.kiwi
# hierarchy. Images with runtime package management ship azurelinux-repos.
# Distroless images intentionally omit repository packages.

base/images/image-hierarchy.html:233

• The first cell in each body row is the row label (for example, a profile name), but it is exposed as an ordinary data cell. Screen readers therefore cannot associate that label with the remaining cells. Mark the first cell as a row header (or render it as <th scope="row">).

                const td = tr.insertCell();
                const value = row[column] || "";
                appendInline(td, value);
                if (value === "X") td.className = "selected";

base/images/images.toml:17

• This switches every existing image to a new build definition, so schema/profile resolution alone does not satisfy the repository's mandatory image validation: it does not execute hooks, create artifacts, or verify boot/runtime behavior. Build and run the configured test suites for the affected images before merging; the PR description explicitly says no full image builds were run.

definition = { type = "kiwi", path = "AzureLinux.kiwi", profile = "vm-base" }

[Copilot]

Pull request overview

Copilot reviewed 24 out of 33 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

base/images/images.toml:33

• Removing the -dev registrations leaves repository callers broken: scripts/build-vm-images.sh:12 still builds vm-base-dev, while scripts/demo-build.sh:27-31 builds and loads container-base-dev; scripts/common.sh:31 also hard-codes the former output path. Those commands now fail because the image names no longer exist. Update these callers in this PR or retain compatible registry entries.

[images.container-base]

[Copilot]

Pull request overview

Copilot reviewed 20 out of 29 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 24 out of 33 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

base/images/images.toml:7

• The new registry removes the existing vm-base-dev, container-base-dev, wsl-dev, and vm-iso-installer-dev image IDs rather than registering all existing images as the summary states. Existing azldev image build <name>-dev automation will now fail and there is no profile that preserves the dev runtime-repository behavior; retain compatibility entries/profiles or document this breaking migration explicitly.

# Every image selects one leaf profile from the shared AzureLinux.kiwi
# hierarchy. Images with runtime package management ship azurelinux-repos.
# Distroless images intentionally omit repository packages.

[Copilot]

Pull request overview

Copilot reviewed 24 out of 33 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

scripts/build-vm-images.sh:8

• The glob is inside the quotes, so the shell treats * literally and this cleanup silently leaves the previous vm-base work tree in place. Quote only the directory prefix so each stale entry is removed before rebuilding.

[Copilot]

Pull request overview

Copilot reviewed 21 out of 30 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

base/images/teams/installer.xml:32

• The new aarch64 installer profile uses ttyAMA0 only for the live ISO, while azl-install*.ks.in, post-install.ks.sh, and the generated target grub.cfg all hard-code console=ttyS0. An aarch64 installation therefore loses its expected serial boot console after reboot. Select the target console by architecture in all generated bootloader settings.

        <type image="iso" flags="dmsquash" filesystem="ext4" kernelcmdline="console=ttyAMA0,115200 console=tty0 enforcing=0 audit=0 inst.text inst.lang=en_US.UTF-8 inst.nokill" firmware="uefi" hybridpersistent="false" mediacheck="true">

[binujp]

Dan Streetman (@ddstreet) this change is the hierarchical implementation of building images the squad is supposed to deliver this cycle. That includes only the 6 images being added and the already added minimal-os image. There are only container images pending. Other variants will have to be added later.

[Copilot]

Pull request overview

Copilot reviewed 25 out of 30 changed files in this pull request and generated no new comments.

Suppressed comments (1)

base/images/images.toml:105

• This redirects minimal-os to the shared hierarchy, but base/images/minimal-os/minimal-os.kiwi remains tracked and is now unreferenced. It is the only obsolete standalone definition left, contrary to the PR's cleanup goal, and creates a second definition that can silently drift. Delete the stale standalone file as part of this migration.

definition = { type = "kiwi", path = "AzureLinux.kiwi", profile = "minimal-os" }

[Copilot]

Pull request overview

Copilot reviewed 25 out of 30 changed files in this pull request and generated no new comments.

Suppressed comments (1)

base/images/images.toml:105

• This registry switch leaves base/images/minimal-os/minimal-os.kiwi as the only obsolete standalone definition in the tree. It is now unreferenced and still advertises the removed minimal-os-dev/azl4-dev behavior, so it can mislead maintainers and drift from this shared profile. Delete that legacy file as part of the stated standalone-definition cleanup.

definition = { type = "kiwi", path = "AzureLinux.kiwi", profile = "minimal-os" }

[Copilot]

Pull request overview

Copilot reviewed 25 out of 30 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

base/images/images.toml:105

• This switches minimal-os to the shared hierarchy, but base/images/minimal-os/minimal-os.kiwi is still tracked even though the PR says obsolete standalone definitions are removed. It is now an unused second definition that can drift from teams/minimal-os.xml; delete the standalone file as part of this migration.

[images.minimal-os]
description = "Minimal OS Image"
definition = { type = "kiwi", path = "AzureLinux.kiwi", profile = "minimal-os" }

[Dan Streetman (ddstreetmicrosoft)]

I left a few more review comments; additionally, having all of this in one single commit makes it really hard to review all the individual changes. I suggest that you break it up into smaller, more reviewable individual commits.

[Dan Streetman (ddstreetmicrosoft)]

question(blocking): aren't we done with the 'stage 1' and 'stage 2' bootstrapping? Shouldn't we just include the azurelinux-repos rpm into some common/core profile instead of having these separate profiles?

[Dan Streetman (ddstreetmicrosoft)]

issue(blocking): this needs to be azurelinux-release-cloud, not azurelinux-release-identity-cloud.

[Dan Streetman (ddstreetmicrosoft)]

issue(blocking):

This defines only three 1p images (gen1, gen1-fips, and gen2-fips) but the PRD defines five (gen1, gen1-fips, gen2, gen2-fips, gen2-cvm). Am I looking at the wrong PRD?

[Dan Streetman (ddstreetmicrosoft)]

question(blocking): I thought vm-base was getting replaced by the images defined in the (marketplace) PRD? Probably by the marketplace-gen2 image?

[Dan Streetman (ddstreetmicrosoft)]

issue(blocking): the description here, and probably in other places, doesn't seem like it is correct?

[Dan Streetman (ddstreetmicrosoft)]

issue(blocking):

I think the iso installer image is sufficiently complex and separated from all of our other images that I'd personally prefer it remain totally separate. Other than a few boot-time packages, it gains basically nothing from being part of our hierarchy of images, and it has a lot of custom scripts and config that I'd prefer stay totally separate from our other images.