c7a9c3b1dd
There's a lot going on here, but essentially: 1. We change the `vmcheck` model so that it always operates on an immutable base image. It takes that image and dynamically launches a separate VM for each test using `kola spawn`. This means we can drop a lot of hacks around re-using the same VMs. 2. Following from 1., `vmoverlay` now takes as input a base image, overlays the built rpm-ostree bits, then creates a new base image. Of course, we don't have to do this in CI, because we build FCOS with the freshly built RPMs (so it uses `SKIP_VMOVERLAY=1`). `vmoverlay` then will be more for the developer case where one doesn't want to iterate via `cosa build` to test rpm-ostree changes. I say "will" because the functionality doesn't exist yet; I'd like to enhance `cosa dev-overlay` to do this. (Note `vmsync` should still works just as before too.) 3. `vmcheck` can be run without building the tree first, as `tests/vmcheck.sh`. The `make vmcheck` target still exists though for finger compatibility and better meshing with `vmoverlay` in the developer case. What's really nice about using kola spawn is that it takes care of a lot of things for us, such as the qemu command, journal and console gathering, and SSH. Similarly to the compose testsuites, we're using parallel here to run multiple vmcheck tests at once. (On developer laptops, we cap parallelism at `$(nproc) - 1`). |
||
|---|---|---|
| .github | ||
| api-doc | ||
| bindgen | ||
| buildutil | ||
| ci | ||
| completion | ||
| design | ||
| docs | ||
| experiments-and-demos/skopeo2ostree | ||
| libdnf@8a6b5837bb | ||
| libglnx@470af8763f | ||
| man | ||
| packaging | ||
| rust | ||
| scripts | ||
| src | ||
| tests | ||
| vagrant | ||
| .cci.jenkinsfile | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitmodules | ||
| .papr.yml | ||
| .vimrc | ||
| autogen.sh | ||
| configure.ac | ||
| CONTRIBUTING.md | ||
| COPYING.GPL | ||
| COPYING.LGPL | ||
| git.mk | ||
| HACKING.md | ||
| LICENSE | ||
| Makefile-bash.am | ||
| Makefile-daemon.am | ||
| Makefile-decls.am | ||
| Makefile-extra.inc | ||
| Makefile-lib-defines.am | ||
| Makefile-lib.am | ||
| Makefile-libdnf.am | ||
| Makefile-libpriv.am | ||
| Makefile-man.am | ||
| Makefile-rpm-ostree.am | ||
| Makefile-tests.am | ||
| Makefile.am | ||
| mkdocs.yml | ||
| OWNERS | ||
| README.md | ||
| Vagrantfile | ||
rpm-ostree: A true hybrid image/package system
rpm-ostree combines libostree (an image system), with libdnf (a package system), bringing many of the benefits of both together.
+-----------------------------------------+
| |
| rpm-ostree (daemon + CLI) |
+------> <---------+
| | status, upgrade, rollback, | |
| | pkg layering, initramfs --enable | |
| | | |
| +-----------------------------------------+ |
| |
| |
| |
+-----------------|-------------------------+ +-----------------------|-----------------+
| | | |
| libostree (image system) | | libdnf (pkg system) |
| | | |
| C API, hardlink fs trees, system repo, | | ties together libsolv (SAT solver) |
| commits, atomic bootloader swap | | with librepo (RPM repo downloads) |
| | | |
+-------------------------------------------+ +-----------------------------------------+
For more information, see the online manual: Read The Docs (rpm-ostree)
Features:
- Transactional, background image-based (versioned/checksummed) upgrades
- OS rollback without affecting user data (
/usrbut not/etc,/var) via libostree - Client-side package layering (and overrides)
- Easily make your own:
rpm-ostree compose treeand CoreOS Assembler
Projects using rpm-ostree
The OSTree project is independent of distributions and agnostic to how content is delivered and managed; it's used today by e.g. Debian, Fedora, and OpenEmbedded derived systems among others. There are some examples in the OSTree github.
In contrast, rpm-ostree is intended to be tightly integrated with the Fedora ecosystem. Today it is the underlying update mechanism of Fedora CoreOS as well as its derivative RHEL CoreOS. It is also used by Fedora IoT and Fedora Silverblue.
Originally, it was productized as part of Project Atomic.
Why?
Package systems such as apt and yum are highly prevalent in Linux-based operating systems. The core premise of rpm-ostree is that image-based updates should be the default. This provides a high degree of predictability and resiliency. However, where rpm-ostree is fairly unique in the ecosystem is supporting client-side package layering and overrides; deeply integrating RPM as an (optional) layer on top of OSTree.
A good way to think of package layering is recasting RPMs as "operating system extensions", similar to how browser extensions work (although before those were sandboxed). One can use package layering for components not easily containerized, such as PAM modules, custom shells, etc.
Further, one can easily use rpm-ostree override replace to override the kernel or userspace components with the very same RPMs shipped to traditional systems. The Fedora project for example continues to only have one kernel build.
Layering and overrides are still built on top of the default OSTree engine - installing and updating client-side packages constructs a new filesystem root, it does not by default affect your booted root. This preserves the "image" nature of the system.
Manual
For more information, see the online manual: Read The Docs (rpm-ostree)
Talks and media
A number of Project Atomic talks are available; see for example this post which has a bigger collection that also includes talks on containers.
rpm-ostree specific talks:
- devconf.cz 2018: Colin Walters: Hybrid image/package OS updates with rpm-ostree slides
- devconf.cz 2018: Peter Robinson: Using Fedora and OSTree for IoT
License
rpm-ostree includes code licensed under GPLv2+, LGPLv2+, (Apache 2.0 OR MIT). For more information, see LICENSE.