From Fedora Project Wiki
mNo edit summary
No edit summary
 
(12 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:ChangePageIncomplete]]
[[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: <will be assigned by the Wrangler>
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KQKCFXG4CTT6IGCGWAXIX5SLHFBFCEAI/ devel thread]
* Tracker bug: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2704 #2704]
* Release notes tracker: <will be assigned by the Wrangler>
* 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 50: Line 56:


* 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)
* We ship e.g. `quay.io/fedora/coreos:stable` and `quay.io/fedora/silverblue:36` etc.
* 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 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 59: 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 65: Line 74:
== Benefit to Fedora ==
== Benefit to Fedora ==


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


== Scope ==
== Scope ==
Line 76: 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: TODO [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* 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

  • 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