F36 Change: ostree native containers / CoreOS layering (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/OstreeNativeContainer

== 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

== Owner ==
* Name: [[User:walters| Colin Walters]]
* Email: [e-mail]

== 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.
* 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]

For more details, please see:

* [https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md
CoreOS layering enhancement]
* [https://coreos.github.io/rpm-ostree/container/ rpm-ostree container docs]
* [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.

== 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
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No

== Documentation ==

Already linked above to avoid duplicating it here.