[RFC] feature: Carry sysext and confext images in COSI files

[Paco Huelsz (frhuelsz)]

What

Adds an RFC proposing that COSI files carry sysext and confext images.

Extension images become ZSTD-compressed members of the COSI tar under
images/extensions/, alongside partition images, and a new optional
extensions section in the COSI metadata describes them. Each entry reuses the
existing ImageFile object and carries an optional destination path, mirroring
the Extension object in the Host Configuration.

Why

An extension is currently a second artefact with a separate lifecycle: hosted
separately, fetched from a second endpoint at deploy time, with integrity
anchored outside os.image.sha384, and updated through a Runtime Update rather
than the A/B update that ships the OS.

Bundling delivers and activates operator content in the same A/B update and the
same reboot as the OS, reusing the existing rollout, health-gating and rollback
machinery. Rollback needs no additional work, since extension images are files
in the target slot's filesystem and the previous slot retains the previous set.

This adds an option rather than replacing one. Extensions deliberately versioned
independently of the OS should continue to use os.sysexts and os.confexts.

Notable decisions

• Two arrays (sysexts, confexts) rather than one with a kind field.
  The kinds have disjoint permitted directories, defaults, extension-release
  locations, identity fields and activation units, and this is the shape the
  Host Configuration already uses.
• Payloads stay under images/. The specification already permits
  subdirectories, so ImageFile.path's ^images/.+ pattern does not need
  relaxing. Relaxing it would produce a 1.3 ImageFile that fails the 1.0-1.2
  schemas.
• Entries carry only image and an optional path. Name, kind, extension
  ID and compatibility metadata are all derivable from the payload.
• Bundled and Host Configuration extensions are merged; a collision is an
  error. Both lists are legitimate at once, and silent precedence would run
  software the image author did not validate, with no visible symptom.
• ID=_any is not warned on or refused. It describes compatibility, not
  delivery. The useful check is the inverse: a bundled ID=<distro> extension
  that does not match the COSI's own osRelease.
• SELinux support is unchanged, but the enforcing-mode check must read the
  merged set rather than the Host Configuration alone.

Two integration points are easy to miss and are called out in the RFC:
osconfig enables systemd-sysext.service and systemd-confext.service based
on the Host Configuration lists being non-empty, and the SELinux dynamic
validation reads the same lists. Both must read the merged set, or a COSI-only
extension configuration is silently unmerged or silently mislabelled.

Open questions

1. Should an override escape hatch exist? The RFC makes a Host Configuration
   versus COSI collision an error. An explicit opt-in on the Host Configuration
   side would permit pinning a hotfixed extension, and equally permit running a
   combination the image author did not validate.
2. Should a bundled extension be suppressible? A deny list has no analogue in
   the current API and no concrete requester.
3. Should path be required? It is optional here for symmetry with
   Extension.path.
4. extensions containing sysexts and confexts, or two top-level arrays?
5. Should Host Configuration extension ID uniqueness be enforced independently
   of this work? It is documented but unenforced today.
6. Should writers be required to place extension payloads after all region
   images, or merely encouraged? The RFC says SHOULD.

Known limitation

An existing Trident accepts any 1.x COSI and ignores unknown fields, so it
will deploy a 1.3 COSI correctly and omit the extensions without reporting
anything. This cannot be corrected in-band for readers that already exist. The
RFC proposes documenting it, warning on unknown minor versions from now on, and
health-check gating where the target's Trident version cannot be controlled.

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.