Re: status update on "ostree native containers"
On Tue, Oct 11, 2022 at 6:40 PM Colin Walters wrote: > > > On Tue, Oct 11, 2022, at 4:22 PM, Micah Abbott wrote: > > So I took a few hours here and there over the last few days to build a > > small project using the ostree native container functionality. I wanted > > to create a variant of Fedora CoreOS (FCOS) that has the Image Builder > > (https://www.osbuild.org/) service layered on top. > > Awesome, I love this demo! > > > I also wanted to > > keep the FCOS layered image up-to-date without any intervention on my > > part. > > Ah yes...so here's the (well, a) neat thing - "rpm-ostree upgrade" already > knows how to do what you're doing externally! So your shell script, timer > and systemd unit are basically equivalent to enabling > `rpm-ostree-automatic.service`, except we are missing a policy of "reboot". > > (I think we started to do that, but then zincati kind of took over the > momentum there for FCOS, on desktop systems one usually wants the GUI to be > in control of reboots, and also in OpenShift we want the MCO to own > reboots. But it'd still make sense) > > I've been thinking recently about whether we should just fold the > functionality from zincati into rpm-ostree...it has grown lots of nice > little tidbits, like monitoring for systemd user sessions and delaying the > reboot, etc. that in theory we want on other systems too. > Ah ha! I was modeling the timer/service approach on the `rpm-ostree-automatic.service` model, but it makes sense that it can work seamlessly with the container image.. I think I got hung up on the lack of a remote definition in `/etc/ostree/remotes.d` for the container image/registry that I rebased to. > > > Overall, the user experience of using a Containerfile to define > > customizations to the OS was really smooth for this use case. > > One pattern I'd recommend that works cleanly instead of having separate > COPY invocations...well actually let me just update one of our examples: > > https://github.com/coreos/coreos-layering-examples/pull/35 Thanks for the pointers! I'll make some changes to that repo and see how it works! > > > > I can > > definitely see how I could expand this workflow to do more testing of > > the layered image before promoting it to the Quay registry, too. > > Yeah...shipping testing tools is a whole other thing. > > > I'm definitely looking forward to seeing how this project progresses in > > the future. > > Awesome, and thanks so much again for posting this! > ___ > 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, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: status update on "ostree native containers"
On 9/27/22 5:08 PM, Colin Walters wrote: But back to Fedora CoreOS, another thing that's happened recently is https://github.com/coreos/coreos-layering-examples has matured and has many functional examples of using this. We're getting increasingly close to the point where I want to call this all stable, so it's a great time if you haven't to kick the tires and try it out! This looks fantastic Colin. I will definitely be checking this out. Joe -- Joe Doss j...@solidadmin.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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: status update on "ostree native containers"
On Tue, Oct 11, 2022, at 4:22 PM, Micah Abbott wrote: > So I took a few hours here and there over the last few days to build a > small project using the ostree native container functionality. I wanted > to create a variant of Fedora CoreOS (FCOS) that has the Image Builder > (https://www.osbuild.org/) service layered on top. Awesome, I love this demo! > I also wanted to > keep the FCOS layered image up-to-date without any intervention on my > part. Ah yes...so here's the (well, a) neat thing - "rpm-ostree upgrade" already knows how to do what you're doing externally! So your shell script, timer and systemd unit are basically equivalent to enabling `rpm-ostree-automatic.service`, except we are missing a policy of "reboot". (I think we started to do that, but then zincati kind of took over the momentum there for FCOS, on desktop systems one usually wants the GUI to be in control of reboots, and also in OpenShift we want the MCO to own reboots. But it'd still make sense) I've been thinking recently about whether we should just fold the functionality from zincati into rpm-ostree...it has grown lots of nice little tidbits, like monitoring for systemd user sessions and delaying the reboot, etc. that in theory we want on other systems too. > Overall, the user experience of using a Containerfile to define > customizations to the OS was really smooth for this use case. One pattern I'd recommend that works cleanly instead of having separate COPY invocations...well actually let me just update one of our examples: https://github.com/coreos/coreos-layering-examples/pull/35 > I can > definitely see how I could expand this workflow to do more testing of > the layered image before promoting it to the Quay registry, too. Yeah...shipping testing tools is a whole other thing. > I'm definitely looking forward to seeing how this project progresses in > the future. Awesome, and thanks so much again for posting this! ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: status update on "ostree native containers"
I've been following the development of the ostree native containers pretty closely, first as a member of the CoreOS team and now as a member of the RHEL for Edge team, but never had a chance to really try it myself. So I took a few hours here and there over the last few days to build a small project using the ostree native container functionality. I wanted to create a variant of Fedora CoreOS (FCOS) that has the Image Builder ( https://www.osbuild.org/) service layered on top. I also wanted to keep the FCOS layered image up-to-date without any intervention on my part. The result is a repo that contains: - a Butane (https://coreos.github.io/butane/) config to generate the initial Ignition (https://coreos.github.io/ignition/) config to provision a "vanilla" FCOS system - a Containerfile that layers the Image Builder bits on top of the "vanilla" FCOS image - a GitHub workflow to automatically build and push an updated layered image to Quay - a hacky systemd service to rebase the "vanilla" system to the new layered image - a hacky systemd service to check for updates to the layered image and apply it to the running system It seems to work in testing, but I only just deployed it "for reals" today, so we'll see if the hands-off update mechanism works the way I want it. Code can be found here - https://github.com/miabbott/fcos-image-builder Overall, the user experience of using a Containerfile to define customizations to the OS was really smooth for this use case. I can definitely see how I could expand this workflow to do more testing of the layered image before promoting it to the Quay registry, too. I'm definitely looking forward to seeing how this project progresses in the future. On Tue, Sep 27, 2022 at 6:09 PM Colin Walters wrote: > We shipped https://fedoraproject.org/wiki/Changes/OstreeNativeContainer > in Fedora 36 and a lot has happened since then. > > One of the biggest things is that rpm-ostree now knows how to > intelligently generate reproducible "chunked" container images. > > I'll describe this by also highlighting another big change; Fedora CoreOS > is now shipped as a properly manifest listed container image alongside the > other Fedora images on quay.io: > https://quay.io/repository/fedora/fedora-coreos > > And if you dig into the tags, on the UI, clicking through to the > stable/amd64 image, check out e.g. > > https://quay.io/repository/fedora/fedora-coreos/manifest/sha256:0d100d21bbe885d638de1847eeacfed7903ed5b9aec5832730d12cad0dbb6f58 > Note that e.g. linux-firmware (by far the largest single chunk) is split > into its own layer - and this layer is generated in a reproducible fashion > (ostree canonicalizes all timestamps to zero in particular). What this > means is that these images share storage on the registry and client side. > > Another way to say this is that it means you get a natural "delta-like" > flow; if e.g. there's a security update to podman, you only download the > layer containing podman (plus a metadata layer), not everything else. > > This isn't the same as more proper deltas (as e.g. ostree static deltas > enable) but it has the powerful benefit of applying everywhere that > Docker/OCI containers go (e.g. when you pull the image via podman/docker or > Kubernetes, that *also* applies there). > > You may see this effort sometimes called "CoreOS Layering" but it really > has little to do with "CoreOS", and https://pagure.io/releng/issue/11047 > is a ticket which proposes shipping e.g. quay.io/fedora/fedora-silverblue > for example. (I know for a number of people I've talked to this idea of > building your desktop as an container image server side is powerfully > appealing, and this makes it real) > > On that topic there's also > https://bugzilla.redhat.com/show_bug.cgi?id=2125655 which shouldn't be > too hard to put together. > > But back to Fedora CoreOS, another thing that's happened recently is > https://github.com/coreos/coreos-layering-examples has matured and has > many functional examples of using this. > > We're getting increasingly close to the point where I want to call this > all stable, so it's a great time if you haven't to kick the tires and try > it out! > ___ > 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, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ 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:
Re: status update on "ostree native containers"
On Tue, Sep 27, 2022, at 6:08 PM, Colin Walters wrote: > We shipped https://fedoraproject.org/wiki/Changes/OstreeNativeContainer > in Fedora 36 and a lot has happened since then. Also, I should mention that we're planning to use this in OpenShift, see https://github.com/openshift/enhancements/blob/master/enhancements/ocp-coreos-layering/ocp-coreos-layering.md and since https://github.com/openshift/machine-config-operator/pull/3317 literally just merged we're on track to use this to update the operating system by default, and further exposing the full power of any container build system you choose (Dockerfile or whatever) to customize the OS in a very Kubernetes/container native way. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: status update on "ostree native containers"
On Wed, Sep 28, 2022, at 9:47 AM, Rahul Sundaram wrote: > FYI, the command in that page doesn't appear to be working because > "latest" is the default tag if you don't specify one for docker and it > doesn't exist, so you have to append ":stable" or something like that. https://github.com/coreos/fedora-coreos-tracker/issues/1309 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: status update on "ostree native containers"
Hi On Tue, Sep 27, 2022 at 6:09 PM Colin Walters wrote: > We shipped https://fedoraproject.org/wiki/Changes/OstreeNativeContainer > in Fedora 36 and a lot has happened since then. > > One of the biggest things is that rpm-ostree now knows how to > intelligently generate reproducible "chunked" container images. > > I'll describe this by also highlighting another big change; Fedora CoreOS > is now shipped as a properly manifest listed container image alongside the > other Fedora images on quay.io: > https://quay.io/repository/fedora/fedora-coreos FYI, the command in that page doesn't appear to be working because "latest" is the default tag if you don't specify one for docker and it doesn't exist, so you have to append ":stable" or something like that. Rahul ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
status update on "ostree native containers"
We shipped https://fedoraproject.org/wiki/Changes/OstreeNativeContainer in Fedora 36 and a lot has happened since then. One of the biggest things is that rpm-ostree now knows how to intelligently generate reproducible "chunked" container images. I'll describe this by also highlighting another big change; Fedora CoreOS is now shipped as a properly manifest listed container image alongside the other Fedora images on quay.io: https://quay.io/repository/fedora/fedora-coreos And if you dig into the tags, on the UI, clicking through to the stable/amd64 image, check out e.g. https://quay.io/repository/fedora/fedora-coreos/manifest/sha256:0d100d21bbe885d638de1847eeacfed7903ed5b9aec5832730d12cad0dbb6f58 Note that e.g. linux-firmware (by far the largest single chunk) is split into its own layer - and this layer is generated in a reproducible fashion (ostree canonicalizes all timestamps to zero in particular). What this means is that these images share storage on the registry and client side. Another way to say this is that it means you get a natural "delta-like" flow; if e.g. there's a security update to podman, you only download the layer containing podman (plus a metadata layer), not everything else. This isn't the same as more proper deltas (as e.g. ostree static deltas enable) but it has the powerful benefit of applying everywhere that Docker/OCI containers go (e.g. when you pull the image via podman/docker or Kubernetes, that *also* applies there). You may see this effort sometimes called "CoreOS Layering" but it really has little to do with "CoreOS", and https://pagure.io/releng/issue/11047 is a ticket which proposes shipping e.g. quay.io/fedora/fedora-silverblue for example. (I know for a number of people I've talked to this idea of building your desktop as an container image server side is powerfully appealing, and this makes it real) On that topic there's also https://bugzilla.redhat.com/show_bug.cgi?id=2125655 which shouldn't be too hard to put together. But back to Fedora CoreOS, another thing that's happened recently is https://github.com/coreos/coreos-layering-examples has matured and has many functional examples of using this. We're getting increasingly close to the point where I want to call this all stable, so it's a great time if you haven't to kick the tires and try it out! ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
