#imgbase

Yet another step towards image based updates using rpms:

[root@localhost ~]# yum update … Installing: ovirt-node-ng-image-update noarch 4.0.0-0.0.master.20160205.0.el7 jenkins.ovirt.org_job_ovirt-node-ng_master_build-artifacts-fc22-x86_64_lastSuccessfulBuild_artifact_exported-artifacts_ 444 M replacing ovirt-node-ng-image-update-placeholder.noarch 4.0.0-0.0.master … Total download size: 447 M Is this ok [y/d/N]:

I actually had this post in my drafts for some while. Now it's more of a reminder than a full post.

We do it, Atomic does it, the systemd-cabal does it, OpenWRT also does it - Delivering the OS or parts of it's - in bigger chunks. We and OpenWrt ship images, atomic trees, and the systemd cabal is also thinking about images.

The projects got in common that due to the similar concepts of delivery, we also share a common set of problems. One problem we all share is, how the state of a system instance - how the system specific configuration - is persisted/kept, between the (image/tree) based updates.

This can seen pragramatically, like it's the defautl way with rpm: The old configuration is not overwritten. But: rpm also has postlets (%post, and others) to apply some logic to files when an rpm is updated. This mechanism is used to i.e. convert files if they need some special handling between version upgrades (db schema migration, binary file conversion, ...). So in the package based scenario, necessary changes to configuration files are done during the package update. The same thing needs to happen with images.

And so all of us, who do a "monolithic os delivery" are facing the same issue: How do we "migrate" the configuration files between image updates - or: How do we persist the state of the system between upgrades.

Besides the technical differences in the solutions to this problem, there is one aspect that is unique1 to systemd: They try to solve conceptual problems.

OpenWRT's luci might be an interestnig approach to persistence; maybe it's more about re-configuration than persistence.

The diagram illustrates how we plan to bring a writable root filesystem to Node, without any limitations. No limitations, because the fs is justa regular filesystem, nothing special about it, the special handling is below, on the block layer, provided by LVM thin volumes (thanks to dm-thin):

. . . . . . . . . . . . . . . . : : : : +--------------+--------------+ : | layer-1 (rw) | layer-2 (rw) | : +--------------+--------------+ : | base-1 (ro) | base-2 (ro) | +------------+ +--------------+--------------+-----------+ | bootloader | | lvm vg | +------------+--+-----------------------------------------+ | disk | +---------------------------------------------------------+

Each image (called base-N) we publish will be stored as a read-only (thin) logical volume in the volume group (lvm vg). For each base base-N a writable layer named layer-N will be created atop of the base. To boot into the writable layers, boot entries will be added to the bootloader, pointing to all available (writable) layers. There is no possibility to boot into the read-only bases.

State If modifying/customizing of a layer is interpreted as the state of a base, then migrating the custom configuration between layers (i.e. migrating the changes to from an old to a new layer), can be called persisting the state of a base.

Apparently there are many ways how the state of a base can be persisted. It has been discussed and will be discussed, yet it is not clear what the Königsweg is.

And it's obvious that base-N is intended to be an ancestor of base-(N+1).

Block layer Hiding the sparseness in the block layer has the big advantage that it is completely transparent to file based stuff, like permissions and (especially) SELinux.