On Tue, Nov 23, 2021 at 11:23 PM Ben Cotton <bcotton@xxxxxxxxxx> 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 > > == 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. > A couple of things from my perspective: * I would like to see how this would enable CoreOS releases to go through Bodhi instead of hiding off to the side as it does now. That also means using registry.fedoraproject.org as the primary registry that replicates to quay.io. * How does this affect Kinoite, Silverblue, and CoreOS releases? Are they changing immediately to this mechanism? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
