From Fedora Project Wiki


ostree native containers (Preview) / CoreOS layering

Summary

Enhance the (rpm-)ostree stack to natively support OCI/Docker containers as a transport and delivery mechanism for operating system content.

This is the basis of https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md

In Fedora 36, this is a "preview" - significant functioning code is shipping, but we are not yet ready to finalize everything and declare that all interfaces and data formats are stable.


Owner

  • Email: walters@verbum.org


Current status

Significant code has been written and is shipping - you can try this today! You need at least rpm-ostree v2021.14 and skopeo 1.5.1

Detailed Description

Having the Fedora ecosystem (from users to release engineering) maintain tooling that operates on all three of "container images", RPMs, and OSTree updates is a maintenance burden.

This proposes that:

  • The ostree stack is enhanced to support encapsulating/unencapsulating ostree commits as OCI/Docker images (DONE)
  • rpm-ostree is updated to consume this, while still supporting all its current features (e.g. per-machine package layering) (DONE)
  • We ship e.g. quay.io/fedora/coreos:stable and quay.io/fedora/silverblue:36 etc. (Current status: quay.io/coreos-assembler/fcos:stable exists)
  • We support deriving new user custom images from these images
  • We enhance this tooling to support chunking

For more details, please see:

Note that significant effort has been invested in ensuring compatibility between what exists in ostree today and OCI/Docker container image "encapsulation". For example, we will continue to reuse the GPG signature infrastructure on OSTree commits that exists today - the ostree tooling knows how to verify the signature *inside* the container image. In the future, we will also likely invest in container-native signatures.

Feedback

Benefit to Fedora

  • Stronger focus on Docker/OCI as transport for operating system and applications
  • New ability to easily create derived operating system images "server side"
  • More benefit from e.g. work on container deltas

Scope

  • Proposal owners:

Lots of detailed items listed in the rpm-ostree/CoreOS docs.

  • Other developers: The "other" here is vague, but certainly developing this so far has needed cooperation with e.g. the containers/ organization etc.
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Objectives: No

Upgrade/compatibility impact

Each individual edition/spin would need to choose when and how to make a cutover to containers as a transport. The Fedora OSTree repository would continue to be maintained until that is finished.


How To Test

See the examples under https://coreos.github.io/rpm-ostree/container/


User Experience

Users of rpm-ostree systems will primarily interact with container images.

Dependencies

Release engineering.

Contingency Plan

  • Contingency mechanism: Continue to ship updates via baseline OSTree
  • Blocks release? No


Documentation

Already linked above to avoid duplicating it here.


Release Notes