## 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@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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to