On Tue, Oct 11, 2022 at 6:40 PM Colin Walters <walt...@verbum.org> 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
