systemd: New bootc-fetch-apply-updates.{timer,service}

[cgwalters]

Let's ship a baseline systemd unit that can be enabled for automatic updates.

[cgwalters]

OK per #179 (comment) let's think about this one a bit more. We should perhaps also have bootc-fetch.service as an explicitly separated unit?

While this project is still classified as "interfaces subject to change", these particular units will be a really important "UX touchpoint" and it'd be good to get them as close to right as we think early on.

This whole thread really intersects with #2 which is a tension I've felt since the start.

[vrothberg]

OK per #179 (comment) let's think about this one a bit more. We should perhaps also have bootc-fetch.service as an explicitly separated unit?

I wonder when such a unit would be useful? Splitting fetching updates from applying them seems special.

If there's a use case to check for an update prior to executing it, callers could do an upgrade --check and then fire the unit.

PR as is LGTM

[jlebon]

OK per #179 (comment) let's think about this one a bit more. We should perhaps also have bootc-fetch.service as an explicitly separated unit?

I wonder when such a unit would be useful? Splitting fetching updates from applying them seems special.

With finalization locking, you can do all the steps ahead of time (fetch and deploy) and minimize down time to just updating the bootloader and restarting.

[cgwalters]

Right, for locking let's reference ostreedev/ostree#3025

[cgwalters]

Actually one thing I'm really strongly opinionated on is that we should default to respecting systemd blocking inhibitors; see coreos/rpm-ostree#2862

It allows the use case of ssh root@examplemachine systemd-inhibit --mode=block bash to debug something reliably.

I am also thinking here that alongside it'd make sense to add an explicit bootc-apply.service (and CLI verb that starts it?) that can have arbitrary hooks added.

For example, zincati today has code to invoke the classic notify via tty code. It's not clear to me that we should duplicate that in bootc, but we could easily support it externally via code that adds a systemd-drop-in that adds ExecStartPre or so?

[cgwalters]

OK, did ostreedev/ostree#3090

[rhatdan]

Is this ready to merge?

[cgwalters]

Actually one thing I'm really strongly opinionated on is that we should default to respecting systemd blocking inhibitors; see coreos/rpm-ostree#2862

We still don't do this...definitely in the nice to have.

[cgwalters]

We're also not using finalization locking here yet. Not fatal, because we're doing an "all-in-one" unit that does everything in one go, so the case of handling out-of-cycle reboots is a bit moot.

[rhatdan]

/lgtm