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@xxxxxxxxxx > > > == 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
