Re: status update on "ostree native containers"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, Oct 11, 2022 at 6:40 PM Colin Walters <walters@xxxxxxxxxx> 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@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, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux