On Wed, Dec 1, 2021 at 5:34 PM Neal Gompa <ngomp...@gmail.com> wrote:
> On Tue, Nov 23, 2021 at 11:23 PM Ben Cotton <bcot...@redhat.com> 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: walt...@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` > <http://quay.io/fedora/coreos:stable> and > > `quay.io/fedora/silverblue:36` <http://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? > Also, how does this intersect with Fedora IoT and their desire to move to Imagebuilder? Overall this looks exciting to me and I love the idea that I can write an Dockerfile (or new thing) file to declare my layering and have it all built (or rebuilt) via existing container tooling. Huzzah! regards, bex > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Did this email arrive after work for you? Stop reading it and enjoy some work/life balance. Brian "bex" Exelbierd (he/him/his) Community Business Owner, RHEL Product Management @bexelbie | http://www.winglemeyer.org bexel...@redhat.com
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
