ostree native containers (Preview) / CoreOS layering
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.
- Name: Colin Walters
- Email: email@example.com
- Targeted release: Fedora Linux 36
- Last updated: 2022-02-25
- devel thread
- FESCo issue: #2704
- Tracker bug: #2030707
- Release notes tracker: #777
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/silverblue:36etc. (Current status:
- 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.
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
- 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.
- Release engineering: https://pagure.io/releng/issue/10399
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: No
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/
Users of rpm-ostree systems will primarily interact with container images.
- Contingency mechanism: Continue to ship updates via baseline OSTree
- Blocks release? No
Already linked above to avoid duplicating it here.