On Tue, Jan 13, 2015 at 7:32 AM, Jaroslav Reznik <jreznik@xxxxxxxxxx> wrote: > = Proposed System Wide Change: RpmOstree - Server side composes and atomic > upgrades = > https://fedoraproject.org/wiki/Changes/RpmOstree > > Change owner(s): Colin Walters <walters@xxxxxxxxxx> > > 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
