Dual Bootable and OCI Image Output with External Registry Publishing for BuildStream

Open
  • Is something wrong?
#5,734 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, python
Domain
devops, infrastructure

Research direction

Start by locating the build_stream and image_build_manager components and reviewing parent issue #5438, then trace how image-thrillhouse currently builds and stages bootable images. Map the existing build and S3 publication flow before defining changes for dual OCI output, external registry authentication, and publishing. Done means all five acceptance criteria pass, including local artifact preservation when publishing fails.

Written by the indexing model from the issue text.

Description

enhancement

Dual Bootable and OCI Image Output with External Registry Publishing for BuildStream

Sub-Issue Context

  • Parent Issue: #5438 (Buildstream Production Readiness and Pilot Acceptance)
  • Component: build_stream / image_build_manager
  • Category: Image Build & Distribution

Summary

BuildStream currently generates materialized, boot-ready OS image bundles (kernel, initramfs, and SquashFS) intended for bare-metal network boot via S3-compatible object storage endpoints. Different customer environments maintain different infrastructure practices and governance models—both S3-compatible object storage and enterprise OCI container registries are common, standard distribution tiers. In many enterprise sites, centralized OCI container registries are already established and integrated into corporate vulnerability scanning, image signing, and access controls.

This capability enhances the BuildStream image build pipeline (backed by image-thrillhouse) to generate dual outputs from a single build pass:

  1. The standard materialized bootable image bundle (kernel, initramfs, SquashFS).
  2. A standard OCI-compliant container image.

Additionally, it allows operators to optionally push the resulting OCI container image directly to an existing, external OCI container registry (e.g., enterprise Harbor, Quay, or internal registry) not managed by Omnia, enabling organizations to distribute and manage cluster OS images using their preferred enterprise container infrastructure.

User Need & Value

  • Architectural Flexibility: Accommodates sites that standardize on enterprise OCI container registries as well as those that utilize S3-compatible object storage endpoints.
  • Dual-Target Efficiency: A single build invocation yields both bare-metal boot components and container-standard OCI images, avoiding redundant build passes and eliminating configuration drift.
  • Enterprise Alignment: Allows cluster operating system images to leverage existing organizational registries, access controls, and security scanning workflows.

Key Capabilities

  1. Dual Image Format Generation:
    • Configure the build pipeline to generate both the bootable kernel/initramfs/SquashFS bundle and the flattened OCI container image as first-class build artifacts from a single catalog recipe.
  2. Optional External Registry Publishing:
    • Provide declarative configuration parameters to authenticate against and push generated OCI images to an existing external registry namespace.
    • Retain local artifact caching so that external pushing is optional and failure to reach an external registry does not destroy locally built boot bundles.
  3. Registry Credential Isolation:
    • Securely manage registry credentials via encrypted credential inputs, supporting standard token-based and username/password authentication mechanisms.
  4. Standard Provenance & Digest Tagging:
    • Tag published OCI images with immutable catalog digests and release tags matching the BuildStream build manifest.

High-Level Scope

Goals
  • Support generating both bootable bundles and OCI images in a single BuildStream run.
  • Enable optional automated pushing of OCI images to an operator-specified external OCI registry.
  • Support standard authentication protocols for external OCI registries (Bearer token, basic auth, TLS verification).
  • Preserve existing local image staging and S3 publication workflows.
Non-Goals
  • Deploying or managing an external container registry instance (the registry must already exist).
  • Deprecating or replacing the standard bare-metal boot bundle output (both formats are preserved).
  • Building application container images (strictly scoped to cluster operating system images).

Acceptance Criteria

  • AC-001: A BuildStream image build generates both the materialized boot bundle (kernel, initramfs, SquashFS) and a valid OCI container image.
  • AC-002: When external registry publishing is enabled with valid credentials, the OCI image is successfully tagged and pushed to the target repository.
  • AC-003: When external publishing is disabled, local bootable artifacts are generated without attempting remote registry network calls.
  • AC-004: Network or authentication failures during remote registry push are reported with actionable error messages without corrupting locally generated boot artifacts.
  • AC-005: Published OCI images contain traceable metadata tags linking them to their source catalog definition.
Dominant language
Python
Stars
9
Forks
175
Avg merge
1d 2h
Merged PRs (30d)
171

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dell/omnia

All issues in dell/omnia

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.