On Tue, Nov 23, 2021, at 12:18 PM, Ben Cotton wrote:
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: walters(a)verbum.org
== 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
Will things be slower than native ostree?
I've got no problem with the capability being added, but I do wonder, Why not rojig,
aka native RPMs plus a special metadata RPM, aka jigdo for ostree? We've already got
great RPM infrastructure. Plus we could get rid of countme.timer and instead ride the
rpm-md connection like the RPM-based variants do.
V/r,
James Cassell