New strategy for background update but interactive reboots

[travier]

Feature Request

Add a new strategy for updates that will always fetch updates as soon as possible in the background, but then notify the admin (in a fashion that remains to be determined, could be motd, or a specific file being written to) and wait for admion confirmation to finalize and reboot.

This is to support podman in a VM on macOS (coreos/fedora-coreos-tracker#768) where we don't want the system to reboot arbitrarily but enable podman commands to remotely check this condition and then show to the user that they can run podman machine update to trigger the update and reboot when they find it convenient.

[lucab]

Happy to push this forward, however this RFE requires some more refining before getting to something implementable.

Here Zincati would be the client to an external / on-hypervisor coordinator, thus we depend on what are the capabilities there and how the environment looks like. Generally speaking there are two possible paths:

• pull-based: Zincati tries to reach the external coordinator, and ask for finalization permission.
  If it is possible to reach it over the network (or localhost), this is effectively already achieved via https://coreos.github.io/zincati/usage/updates-strategy/#lock-based-strategy.
  If network-based coordination is not possible, we'd need to know what are other possible options available in that environment.
• push-based: the external coordinator pushes (and withdraws) the finalization permission directly to Zincati (or at least to the VM).
  This is the direction where strategy: add new marker_file strategy #540 is going, by using the local filesystem. It sounds like we can directly use that or build something similar (depending on the needs).
  In any case, we have to add a way for Zincati to signal that there is a pending finalization. I guess either via dbus or a marker file (or both).

In the push-based scenario a key point which should be clarified is, in case of multiple queued updates (e.g. because of barriers), whether the coordinator wants to acknowledge every single finalization requests or whether it prefers setting some kind of declarative allow-window (eg. capped by time, or number of upgrades) to reach the final version.

[travier]

I think what they need is a push-based path with single shot updates. Each update will require user intervention. I don't think the VM will have access to the host and there probably won't be any daemon running there.

We need a "fast-and-cheap-to-check" marker as they will probably have to do the check for every single podman command so a dbus calls might be too expensive.

[dustymabe]

got asked by Brent Baude in #podman about this today. Would be nice to pick it up and push it over the finish line if we can.

[jlebon]

I think this is closely related to #498.