< Changes
mNo edit summary |
No edit summary |
||
| (10 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | ||
= ostree native containers / CoreOS layering = | = ostree native containers (Preview) / CoreOS layering = | ||
== Summary == | == Summary == | ||
| Line 9: | Line 9: | ||
This is the basis of https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md | 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. | |||
| Line 21: | Line 23: | ||
== Current status == | == Current status == | ||
[[Category: | [[Category:ChangeAcceptedF36]] | ||
Significant code has been written and is shipping - you can try this today! You need at least [https://bodhi.fedoraproject.org/updates/FEDORA-2021-5e6a48669c rpm-ostree v2021.14] and [https://bodhi.fedoraproject.org/updates/FEDORA-2021-b8fee395ca skopeo 1.5.1] | |||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
| Line 39: | Line 44: | ||
ON_QA -> change is fully code complete | ON_QA -> change is fully code complete | ||
--> | --> | ||
* FESCo issue: | * [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KQKCFXG4CTT6IGCGWAXIX5SLHFBFCEAI/ devel thread] | ||
* Tracker bug: | * FESCo issue: [https://pagure.io/fesco/issue/2704 #2704] | ||
* Release notes tracker: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2030707 #2030707] | ||
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/777 #777] | |||
== Detailed Description == | == Detailed Description == | ||
| Line 51: | Line 57: | ||
* The ostree stack is enhanced to support encapsulating/unencapsulating ostree commits as OCI/Docker images (DONE) | * 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) | * 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. | * 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 support '''deriving''' new user custom images from these images | ||
* We enhance this tooling to [https://github.com/ostreedev/ostree-rs-ext/issues/69 support chunking] | * We enhance this tooling to [https://github.com/ostreedev/ostree-rs-ext/issues/69 support chunking] | ||
| Line 60: | Line 66: | ||
* [https://coreos.github.io/rpm-ostree/container/ rpm-ostree container docs] | * [https://coreos.github.io/rpm-ostree/container/ rpm-ostree container docs] | ||
* [https://github.com/ostreedev/ostree-rs-ext/ ostree-rs-ext project] | * [https://github.com/ostreedev/ostree-rs-ext/ ostree-rs-ext project] | ||
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 == | == Feedback == | ||
| Line 77: | Line 85: | ||
* Other developers: The "other" here is vague, but certainly developing this so far has needed cooperation with e.g. the containers/ organization etc. | * 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: | * Release engineering: https://pagure.io/releng/issue/10399 | ||
* Policies and guidelines: N/A (not needed for this Change) | * Policies and guidelines: N/A (not needed for this Change) | ||
Latest revision as of 14:12, 25 February 2022
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
- Name: Colin Walters
- 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
- Targeted release: Fedora Linux 36
- Last updated: 2022-02-25
- devel thread
- FESCo issue: #2704
- Tracker bug: #2030707
- Release notes tracker: #777
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:stableandquay.io/fedora/silverblue:36etc. (Current status:quay.io/coreos-assembler/fcos:stableexists) - 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.
- 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
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.