transactional-update is an application that allows to update a Linux system and its applications in an atomic way: The update will be performed in the background, not influencing the currently running system. The update will be activated by a reboot instead, similar to rpm-ostree or CoreOS' previous Container OS. However transactional-update is not another package manager, but is reusing the existing system tools such as RPM as the packaging format and zypper as the package manager. It depends on Btrfs due to its snapshotting and copy-on-write features.
The idea and reason to build up on existing tools is the ability to continue using existing packages and tool chains for delivery and application of updates. While currently only implemented for (open)SUSE environments the concept is vendor independent and may also be implemented for other package managers and package formats.
Conceptually transactional-update creates a new snapshot with btrfs before performing any update and uses that snapshot for modifications. Since btrfs snapshots contain only the difference between two versions and thus are usually very small updates done with transactional-update are very space efficient. This also means several snapshots can be installed at the same time without a problem.
A transactional update (also known as atomic upgrade) is an update that
The update does not influence the running system.
The machine can be powered off at any time. When powered on again either the unmodified old state or the new state is active, but no state in between.
can be rolled back:
If the upgrade fails or if a newer software version turns out to not be compatible with your infrastructure, the system can quickly be restored to a previous state.
Linux distributions have had working update mechanisms for many, many years - so why do we need something new? Distributions evolved, introducing new concepts such as rolling releases, containers or long time support releases. While the classical update mechanisms are probably perfectly fine for a regular desktop user, using a distribution with regular releases, other concepts may require different concepts.
Distributions with rolling updates face the problem: how should intrusive updates be applied to a running system - without breaking the update mechanism itself? Examples like the migration from SysV init to systemd, a major version update of a desktop environment while the desktop is still running or even only a small update to D-Bus may give a good idea of the problem. The desktop environment may simply terminate, killing the update process and leaving the system in a broken, undefined state. If any update breaks such a system there needs to be a quick way to roll back the system to the last working state.
On mission critical systems you want to make sure that no service or user behaviour interferes with the update of the system. And conversely the update should not modify the system, e.g. by uncontrolled restarts of services or unexpected modifications to the system in post scripts. Potential interruptions are deferred to a defined maintenance window instead. For really critical systems the update can be verified (e.g. using snapper diff) or discarded before actually booting into the new system. If an update encounters an error the new snapshot will be discarded automatically.
For cluster nodes it is important that the system is always in a consistent state, requires no manual interaction and is able to recover itself from error conditions. For these systems transactional-updates provides automatic updates; snapshots with failed updates will be automatically removed. Automatic reboots can be triggered using a variety of different reboot methods (e.g. rebootmgr, kured or systemd), making the appliance of the updates cluster aware.
Sometimes new kernel versions or software updates are incompatible with your hardware or other software. In this case there should be a quick and easy way to roll back to the state before the update was applied.
There are other solutions available for the above problems, like downloading all RPMs upfront and apply them during the boot phase. This however will block the system for an unknown period of time while the update is running, delaying the availablility of the system.