What’s new in rpm-ostree - 2022 Edition!

Colin Walters

January 23, 2022

Who/why?

  • Colin Walters, Red Hat, Inc. - Fedora/OpenShift/RHEL/CoreOS engineer
  • Why: Computing essential to society, FOSS essential to control computing

Overview

  • Transactional background OS upgrades
  • Image based by default, but still a Linux system
  • Separating applications into containers helps upgrades
  • Good integration with RPM because we can’t change (our subset of the) world at once

Where’s rpm-ostree used today?

What’s actually new in the last ~year?

  • OSTree native containers
  • Increasing oxidation (conversion to Rust)
  • Finally support for modularity
  • Reproducible builds
  • Big shuffle of support for sqlite rpmdb
  • Respect systemd inhibitors for rpm-ostree upgrade -r
  • DNF Count Me support

What’s actually new page 2

  • 2021.1: ex apply-live
  • 2021.3 rpm-ostree install -A stabilized 🎉
  • Also in that release, we switched to a Rust app with C/C++ library

OK more about ostree native containers

  • What: FROM quay.io/fedora/coreos RUN rpm-ostree install usbguard && ADD usbguard.conf
  • Why: Create a bridge between worlds (“pristine/golden/immutable” host, traditional OS)
  • Also between container stack and host
  • How: ~6000 lines of new Rust code in ostree-rs-ext, including a proxy to the containers/Go ecosystem.

Rethinking rpm-ostree systems as base images

  • Note: Everything that works today will continue to work
  • (Except we will probably switch Fedora and derivatives to transport via container image)
  • One might think of this as “Server side package layering”…but also bind configuration and code
  • Also, inject non-RPM content! Should be equally “first class”.
  • Could also e.g. derive Fedora Silverblue from FCOS

Status: Works, but still experimental

More on the (configuration, code, state) 3-tuple

  • Corresponds to /etc, /usr, /var
  • OSTree operates on /etc and /usr, will never ever touch /var
  • The “base images” we ship are unconfigured (obviously!). Configuration systems: Anaconda (often paired with something else), Ignition (or cloud-init)
  • With this model, you can exactly bind your configuration with your code as a container image.
  • Very big change vs Ignition’s “configure once” model
  • Related: NixOS, OpenShift MCO, Ansible

User story

  • Build a container with preferred OS state
  • Boot from our disk images, early at install/boot run rpm-ostree rebase ostree-unverified-registry:quay.io/example/custom:latest --reboot (better signed, lots of details there)
  • Enable automatic upgrades
  • Pushing a new container will upgrade your systems
  • Probably expose ability to go container → disk image in e.g. osbuild/Image Builder and the like

Alternative history

  • Pretend dual paritition dm-verity (orig Container Linux) and ostree, etc. hadn’t happened
  • A few years pass of Docker then Kubernetes
  • What if we made the host OS boot this way too? (xref linuxkit balena etc.)

What will happen in 2022?

  • Several people are committed to this
  • Splitting image layers will be a huge effort too.
  • Would like to push forward more docs and ex apply-live, continue oxidation. And rethinking origins.
  • But willing to help with other PRs!