## Strengthening the notion of an "updates driver" Distributions like Fedora CoreOS have been making use of external (to rpm-ostree) agents that work as "drivers" for automatic updates. For example, in FCOS, Zincati is the agent that is responsible for communicating with an updates server to identify legal update paths and scheduling updates. In FCOS, there are certain well-tested paths for updates, dead-end releases, as well as "barrier updates". Agents like Zincati interact with rpm-ostree on behalf of the admin to make the right decisions for seamless automatic updates. However, prior to this release, rpm-ostree had been allowing manual updates via `rpm-ostree upgrade`. Because rpm-ostree has no knowledge of update graphs, the problem with this is that it would allow for admins to e.g. blow past FCOS' barrier updates, or update to releases that aren't meant to be reached from the current release. The client-side now supports a `--register-driver` command to tell rpm-ostree that another service is actively "driving" updates. This lets rpm-ostree know some basic information about the updates driver (name and systemd unit) and allows rpm-ostree to be aware that updates should not be done manually. `rpm-ostree status` now shows the state of the registered updates driver, as well. In concert with this, `rpm-ostree upgrade` now emits an error message if a driver is registered. Nevertheless, there are scenarios where admins may want to force an upgrade despite an updates driver being present on the system; a possible scenario would be when the admin knows of an available update and would like to immediately upgrade to it, but the updates driver hasn't detected it yet (possibly due to phased rollouts or low update-checking cadence), or the updates driver has scheduled it for later. `rpm-ostree upgrade` offers a `--bypass-driver` option to address scenarios like this. This option should be used with caution, and ideally only when the admin knows that the update target moves along a legal edge in the distribution's updates graph. In the future, we would like more communication between rpm-ostree and its updates driver and have rpm-ostree check with the updates driver before doing a manual upgrade. PRs: https://github.com/coreos/rpm-ostree/pull/2459, https://github.com/coreos/rpm-ostree/pull/2525, and https://github.com/coreos/rpm-ostree/pull/2566 ## Compose There is a new `rpm-ostree compose extensions` which will be used by RHEL CoreOS, but is intended to be generally usable by rpm-ostree users that want to more cleanly split their builds into "base OS image" + "optional extensions (RPMs)", while reusing the same declarative manifest format. PR: https://github.com/coreos/rpm-ostree/pull/2439 ## Core changes rpm-ostree now better supports a newer libsolv that uses `%{_dbpath}` to find the rpm database. (This fix was already backported into Fedora) Issue: https://github.com/coreos/rpm-ostree/issues/2548 ## Internals [Change main entrypoint to be Rust](https://github.com/coreos/rpm-ostree/pull/2502) is a huge milestone - rpm-ostree is now a Rust application with an internal C++ library. We now do [bidirectional calls](https://github.com/coreos/rpm-ostree/pull/2413). The transition to Rust is accelerating! Other oxidation progress: - Much of the code around handling `/etc/{passwd,group}` is now in Rust; PR: https://github.com/coreos/rpm-ostree/pull/2580 A lot of CI fixes and cleanups; most notably we now test some with [AddressSanitizer](https://clang.llvm.org/docs/AddressSanitizer.html) which caught one bug. ## Bodhi Here's the [rpm-ostree v2021.2 Bodhi update](https://bodhi.fedoraproject.org/updates/FEDORA-2021-476111013d)! _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
