#ostree

Yet another post (Jasper) on image based OS deliveries. Jasper is also utilizing ostree which become widely known with the Fedora Atomic or Project Atomic effort. And there is also the idea from the systemd people which got some attention.

It's not that image based OS delivery is new. oVirt Node is around for some years and is an example of an image based OS with atomic upgrades. Maintaining this small project gives us some experience, and we also see the limitations of our current approach, this is the reason why we are also investigating how to redesign Node, and keep the image based delivery. There are similarities between Node's requirements and the use cases addressed byostree and the systemd people, so we also keep close eye on those projects. One difference we, especially to ostree is, that Node is an appliance intended to be the OS of a bare-metal machine, which needs to be somewhat customizable at runtime.

OStree is nice. Several filesystem trees exist in parallel on a host. Upgrades happen by creating a new tree. The efficiency comes from reducing redundancies between the different trees. The problem we currently see with this approach, is that we can not really customize the parts we need to modify: Adding 3rd party kernel modules and adding custom monitoring tools. Sure, there is a POC for installing simple rpms at runtime, and it is possible to create new trees on the server side.

systemd-btrfs-composing is a very interesting but young idea. I'm a bit sceptical that it's tied to a single filesystemn, but let's see. Functional it would provide us with all the features we need: Booting into a real filesystem, which is completely writable. Beyond that - which makes this idea unqiue IMO - is the strong focus on changing the way how (especially) configuration is re-thought to make the separation of stateless (site unspecific, like libraries) and statefull (site specific, like configurations) possible. I'm thinking about the idea of moving default configurations to some factory directory.

image based is the idea we've come up with. It's basically a specific LVM usage pattern. It is an old idea, but realized in a stricter way. Node will become a rootfs (like the trees provided by ostree). Those root filesystems can be pulled and are pushed into local logical volumes. The volumes are read-only, and a writable thin volume is created atop the read-only volume. This concept is very similar to the backingstore concept of the qcow2 format. Anyhow, the writable layer is used to boot the host.

Updates are (partially) simple: A new root filesystem is pushed into a new (read-only) logical volume, a writable layer is created a top, and a new boot entry is added.

Compared to ostree, we don't boot into trees in a filesystem, we rather boot into different filesystems. This has the benefit of beeing very close to a regular operating system.