Skip to content

chore(comps): annotate overlays in multiple categories with metadata#17888

Open
liunan-ms wants to merge 7 commits into
4.0from
liunan/azl-annotations
Open

chore(comps): annotate overlays in multiple categories with metadata#17888
liunan-ms wants to merge 7 commits into
4.0from
liunan/azl-annotations

Conversation

@liunan-ms

@liunan-ms liunan-ms commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Summary
This PR migrates the overlay definitions for the five overlay-classifier categories — azl-branding-policy, azl-dep-missing-workaround, azl-platform-adaptation, azl-release-management, and azl-security-compliance — to the per-file overlay layout with file-level metadata. This is a pure restructuring/annotation change: no overlay is added, removed, reordered, or semantically altered, and the rendered specs are byte-identical to 4.0.

Complements the sibling PRs #17727, #17886, #17887 . Components already migrated on those branches are skipped.

Changes
30 components migrated across five per-category commits (one commit per category for easy review/grouping):

Commit Category Components
chore(comps): annotate azl-branding-policy… azl-branding-policy (5) anaconda-webui, azurelinux-rpm-config, chrony, realmd, rpm
chore(comps): annotate azl-dep-missing-workaround… azl-dep-missing-workaround (8) erlang-rebar3, golang-github-envoyproxy-control-plane, golang-github-prometheus-common, golang-mongodb-mongo-driver, libnbd, migrate, nbdkit, pyOpenSSL
chore(comps): annotate azl-platform-adaptation… azl-platform-adaptation (9) kernel, openbios, rust-nix, rust-nix0.23, rust-nix0.28, rust-nix0.29, rust-nix0.30, selinux-policy, vmaf
chore(comps): annotate azl-release-management… azl-release-management (5) gd, java-25-openjdk, rust-dlwrap, shim-unsigned-aarch64, shim-unsigned-x64
chore(comps): annotate azl-security-compliance… azl-security-compliance (3) firewalld, openfec, openssl

Two supporting commits:

  • chore(distro): set overlay-files default-component-config - ⚠️ PR-CHECK ONLY, REVERT BEFORE MERGE
    Temporary. Sets overlay-files = ["overlays/*.overlay.toml"] in the 4.0 stage1/stage2 default-component-config, so every component inherits per-file overlay discovery (no per-component key needed). Standalone so it can be reverted independently.

  • chore(azldev): pin to 35d8fae and regenerate schema - ⚠️ PR-CHECK ONLY, REVERT BEFORE MERGE
    Temporary. Pins .azldev-version to 35d8fae (merged form of azure-linux-dev-tools#256: inheritable overlay-files + empty-list override) and regenerates external/schemas/azldev.schema.json so PR checks run against a tool that understands the new overlay-files / metadata / BugRef fields. Must be reverted before this PR merges.

Validation
✅ Structural no-op: all 30 components' reconstructed overlay lists are byte-identical to 4.0.
azldev component list -a parses cleanly (7424 components).
comp render in PR check

liunan-ms and others added 7 commits July 1, 2026 22:25
Migrate 5 component(s) whose overlays are predominantly azl-branding-policy
to the per-file overlay layout. Each component's inline overlays move into
per-group overlays/*.overlay.toml files (one file per logical group, even
for single-overlay components), carrying a file-level [metadata] block with
category and upstreamable. Multi-category components get one file per group,
each stamped with that group's own category.

overlay-files is intentionally NOT added (neither per-component nor in the
distro default-component-config), so this is a pure restructuring: overlay
values, order, and comp.toml comments are preserved byte-for-byte (validated
as a structural no-op against 4.0).

Interleaved component(s) azurelinux-rpm-config are consolidated into a single per-component overlay file to
preserve their exact original apply order (their report groups interleave);
the file carries the dominant category (azl-branding-policy).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Migrate 8 component(s) whose overlays are predominantly azl-dep-missing-workaround
to the per-file overlay layout. Each component's inline overlays move into
per-group overlays/*.overlay.toml files (one file per logical group, even
for single-overlay components), carrying a file-level [metadata] block with
category and upstreamable. Multi-category components get one file per group,
each stamped with that group's own category.

overlay-files is intentionally NOT added (neither per-component nor in the
distro default-component-config), so this is a pure restructuring: overlay
values, order, and comp.toml comments are preserved byte-for-byte (validated
as a structural no-op against 4.0).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Migrate 9 component(s) whose overlays are predominantly azl-platform-adaptation
to the per-file overlay layout. Each component's inline overlays move into
per-group overlays/*.overlay.toml files (one file per logical group, even
for single-overlay components), carrying a file-level [metadata] block with
category and upstreamable. Multi-category components get one file per group,
each stamped with that group's own category.

overlay-files is intentionally NOT added (neither per-component nor in the
distro default-component-config), so this is a pure restructuring: overlay
values, order, and comp.toml comments are preserved byte-for-byte (validated
as a structural no-op against 4.0).

Interleaved component(s) kernel are consolidated into a single per-component overlay file to
preserve their exact original apply order (their report groups interleave);
the file carries the dominant category (azl-platform-adaptation).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Migrate 5 component(s) whose overlays are predominantly azl-release-management
to the per-file overlay layout. Each component's inline overlays move into
per-group overlays/*.overlay.toml files (one file per logical group, even
for single-overlay components), carrying a file-level [metadata] block with
category and upstreamable. Multi-category components get one file per group,
each stamped with that group's own category.

overlay-files is intentionally NOT added (neither per-component nor in the
distro default-component-config), so this is a pure restructuring: overlay
values, order, and comp.toml comments are preserved byte-for-byte (validated
as a structural no-op against 4.0).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Migrate 3 component(s) whose overlays are predominantly azl-security-compliance
to the per-file overlay layout. Each component's inline overlays move into
per-group overlays/*.overlay.toml files (one file per logical group, even
for single-overlay components), carrying a file-level [metadata] block with
category and upstreamable. Multi-category components get one file per group,
each stamped with that group's own category.

overlay-files is intentionally NOT added (neither per-component nor in the
distro default-component-config), so this is a pure restructuring: overlay
values, order, and comp.toml comments are preserved byte-for-byte (validated
as a structural no-op against 4.0).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Enable per-file overlay discovery for every component by setting
overlay-files = ["overlays/*.overlay.toml"] in the 4.0 stage1/stage2
default-component-config. This is what makes the migrated components'
overlays/*.overlay.toml files load. Kept as a standalone latest commit so
it can be reverted independently of the annotation migration.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… BEFORE MERGE]

TEMPORARY: this commit exists solely so the PR checks run against an azldev
build that understands the new overlay-files / metadata / BugRef config. It
MUST be reverted before the PR is merged.

Pin azldev to 35d8fae562980db7bda057d79322cc51ddad8d62, the merged form of the
overlay-files-after-resolution change (microsoft/azure-linux-dev-tools#256).
This version supports inheriting overlay-files from a project-wide
[default-component-config] and allows an empty overlay-files list to disable
inherited patterns. Regenerate external/schemas/azldev.schema.json against the
pinned tool so the authoritative schema knows the new metadata / overlay-files /
BugRef fields.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR continues a multi-PR effort to annotate Azure Linux overlays with structured provenance [metadata] and migrate them from inline [[components.<name>.overlays]] / overlays = [...] definitions into the per-file overlays/*.overlay.toml layout. It covers 30 components spanning five overlay-classifier categories (azl-branding-policy, azl-dep-missing-workaround, azl-platform-adaptation, azl-release-management, azl-security-compliance), and is intended to be a pure restructuring/annotation change with rendered specs byte-identical to 4.0. It complements sibling PRs #17727, #17886, and #17887.

Changes:

  • Moves each component's overlays into overlays/*.overlay.toml files carrying a file-level [metadata] block (category + upstreamable), preserving original comments; regex literals are re-escaped for basic strings and source paths rewritten to ../ (relative to the overlay file).
  • Two temporary "PR-CHECK ONLY, REVERT BEFORE MERGE" scaffolding changes: sets an inherited overlay-files in the 4.0 stage1/stage2 default-component-config, and pins .azldev-version to 35d8fae + regenerates the JSON schema (adds OverlayMetadata, overlay-files, resources, etc.).
  • Migration verified as byte-identical: regex escaping, source-path rewrites, and per-component overlay counts are all preserved (spot-checked across selinux-policy, openssl, chrony, java-25-openjdk, kernel, azurelinux-rpm-config, and others).

The only issue found is cosmetic: the kernel overlay file's conversion of triple-quoted multi-line replacement strings into single-line \n strings left behind stray trailing fragment lines. They are inert TOML comments (render output is unaffected) but should be cleaned up.

Reviewed changes

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

Show a summary per file
File Description
external/schemas/azldev.schema.json Regenerated schema: adds OverlayMetadata, overlay-files, BugRef, resources/DistroVersionInputs defs (temp, revert-before-merge)
distro/azurelinux.distro.toml Adds inherited overlay-files to 4.0 stage1/stage2 default-component-config (temp, revert-before-merge)
.azldev-version Pins azldev to 35d8fae (temp, revert-before-merge)
base/comps/kernel/overlays/0001-azl-kernel-customizations.overlay.toml Migrated kernel overlays; contains stray """ fragment lines from the multi-line→single-line conversion
base/comps/kernel/kernel.comp.toml Inline kernel overlays removed (moved to overlay file)
base/comps/azurelinux-rpm-config/* Inline overlays = [...] array migrated to per-file layout; source rewritten to ../dist.sh
base/comps/{shim-unsigned-x64,shim-unsigned-aarch64,rust-dlwrap,gd,java-25-openjdk}/* azl-release-management overlays migrated
base/comps/{anaconda-webui,chrony,realmd,rpm}/* azl-branding-policy overlays migrated
base/comps/{erlang-rebar3,golang-,libnbd,migrate,nbdkit,pyOpenSSL}/ azl-dep-missing-workaround overlays migrated
base/comps/{openbios,rust-nix,rust-nix0.23/0.28/0.29/0.30,selinux-policy,vmaf}/* azl-platform-adaptation overlays migrated; patch source rewritten to ../
base/comps/{firewalld,openfec,openssl}/* azl-security-compliance overlays migrated

@liunan-ms liunan-ms marked this pull request as ready for review July 2, 2026 05:19
@liunan-ms liunan-ms requested a review from a team as a code owner July 2, 2026 05:19

@tobiasb-ms tobiasb-ms left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I spot-checked some things and the fact that the spec renderer ran and didn't complain -- despite no changes to specs/ -- indicates this is a functional no-op. Approved.


[metadata]
category = "azl-branding-policy"
upstreamable = false

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should absolutely be upstreamed.

@@ -0,0 +1,21 @@
[metadata]
category = "azl-branding-policy"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is a fair use of branding-policy as a category.

# broken erlang-rebar3 3.26.0 in the build tag. The latest upstream commit
# disabled bootstrap (since Fedora already has a working 3.27.0), but AZL
# doesn't yet.
# TODO: Remove this overlay once rebar3 3.27.0 is in the AZL build tag.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we capture that this is a temporary workaround that needs action?

@@ -0,0 +1,10 @@
[metadata]
category = "azl-dep-missing-workaround"
upstreamable = false

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a legit upstream issue, then?

@@ -0,0 +1,276 @@
# Insert version and release information from the component defines into the spec file, and update the source URL to match the AzureLinux kernel source structure

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get that we might not want to in this PR, but can we file a bug to break this up? This is definitely crying out for multiple .overlay.toml files.

@@ -0,0 +1,9 @@
[metadata]
category = "azl-dep-missing-workaround"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How are we deciding when to use dep-missing-workaround vs. prune? I'm not sure I have a good mental model.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants