F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades

[Josh Boyer]

On Tue, Jan 13, 2015 at 7:32 AM, Jaroslav Reznik <jreznik at redhat.com> wrote:
> = Proposed System Wide Change: RpmOstree - Server side composes and atomic
> upgrades =
> https://fedoraproject.org/wiki/Changes/RpmOstree
>
> Change owner(s): Colin Walters <walters at verbum.org>
>
> The rpm-ostree [1] tool provides a new way to deploy and manage RPM-based
> operating systems. Instead of performing a package-by-package install and
> upgrade on each client machine, the tooling supports "composing" sets of
> packages on a server side, and then clients can perform atomic upgrades as a
> tree.
>
> The system by default preserves the previously booted deployment, providing an
> "A/B partition" type feel, allowing quick system rollbacks for the entire OS
> content (kernel and userspace).
>
> This is a dependency of the Changes/Atomic_Cloud_Image. [2]

Erm.. if this change is a dependency for the above, did the above wind
up not making F21?  If so, should it be moved to F22?

> == Detailed Description ==
> rpm-ostree is far from the first effort in the field of "image-like" update
> systems in Fedora. The StatelessLinux [3] project was first prototyped in
> Fedora Core 6 timeframe. Today, particularly in the cloud, many deployments
> perform OS upgrades by terminating an instance, and booting a new OS image and
> having it discover previous state stored in an external volume or network
> store.
>
> Another model is to perform an atomic upgrade by delivering the OS content via
> an ISO or USB stick, and simply swapping it out, then rebooting. The oVirt
> Node [4] is an example of this model.
>
> The most challenging case though is stateful systems that require
> online/incremental Internet/Intranet connected upgrades. This is the default
> model for traditional Fedora package managers such as yum. A common approach
> for this to have an "A/B" partition model, and to use rsync or a custom tool
> to perform upgrades offline into the non-active partition.
>
> rpm-ostree is attempting to address this last case, but in a more flexible and
> dynamic fashion. It has some of the flexibility of package systems, with the
> atomic upgrade and rollback of image-based systems. Furthermore, rpm-ostree
> intends to bind together the world of packages with an image-like update
> system. For example, an "rpm-ostree upgrade" command can show the system
> administrator the package-level diff.
>
> In the future, the intention is for rpm-ostree to further gain package-system
> like features. See package layering prototype [5]. An active git branch uses
> libhif [6].
>
> == Scope ==
> * Proposal owners: work on http://projectatomic.io upstream
>
> * Other developers:
> ** Anaconda: Help maintain rpmostreepayload.py
> ** Anaconda/Architecture porters: Backends for the OSTree bootloader code,
> similar to grubby
>
> ** RPM content:
> *** Use systemd-tmpfiles instead of placing content in /var  (TODO: better docs
> for this)
> *** Change "rootfiles" and "bash" to not require files in /root by default
> (TODO: bugzilla entry)
>
> * Release engineering: Create trees from package set, mirroring support
>
> * Policies and guidelines: TODO: Guideline for /var

Jaroslav, there is a lot more information on the actual wiki page.
Like the fact that this is only for particular opt-in new installs and
that yum/dnf/RPM can only operate in read-only mode on such installs.
Could you resend this with the entirety of the text?  It might lead to
fewer questions.

josh