< Changes
(Created page with "<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> = ...") |
No edit summary |
||
| Line 4: | Line 4: | ||
== Summary == | == Summary == | ||
The | The [https://github.com/projectatomic/rpm-ostree rpm-ostree] 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). | 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). | ||
| Line 20: | Line 20: | ||
== Detailed Description == | == Detailed Description == | ||
rpm-ostree is far from the first effort in the field of "image-like" update systems in Fedora. The [[ | rpm-ostree is far from the first effort in the field of "image-like" update systems in Fedora. The [[StatelessLinux]] 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 | 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 [http://www.ovirt.org/Node_Building oVirt Node] 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 the default Fedora packaging model. | The most challenging case though is stateful systems that require online/incremental Internet/Intranet connected upgrades. This is the default model for the default Fedora packaging model. | ||
| Line 29: | Line 29: | ||
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. | 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 | In the future, the intention is for rpm-ostree to further gain package-system like features. See [https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2014-October/msg00005.html package layering prototype ]. | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
| Line 55: | Line 55: | ||
== Dependencies == | == Dependencies == | ||
The rpm-ostree tooling depends on and intends to integrate with other fundamental Fedora components such as Anaconda. It makes use of the new | The rpm-ostree tooling depends on and intends to integrate with other fundamental Fedora components such as Anaconda. It makes use of the new [https://github.com/rpm-software-management/hawkey hawkey] library which is a component underlying [https://github.com/rpm-software-management/dnf dnf]. | ||
Revision as of 15:33, 6 November 2014
RpmOstree - Server side composes and atomic upgrades
Summary
The rpm-ostree 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.
Owner
- Product: Fedora All
- Responsible WG: FESCO ?
Current status
- Targeted release: Fedora 22
- Last updated: 2014-11-06
- Tracker bug: None yet
Detailed Description
rpm-ostree is far from the first effort in the field of "image-like" update systems in Fedora. The StatelessLinux 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 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 the default Fedora packaging model. 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 .
Benefit to Fedora
A server-side compose mechanism for atomic upgrades can be used by many deployments where Fedora is used.
Scope
- Anaconda (mostly done)
- Multiple architecture porting for the OSTree bootloader code (ARM/ppc/etc.)
- RPM content (examples, non-exhaustive)
- Use systemd-tmpfiles instead of placing content in /var
- Change "rootfiles" and "bash" to not require files in /root by default
- PackageKit (not started)
Upgrade/compatibility impact
Existing installations will continue to function as before with the previous system's package manager; this feature is opt-in for new installations. (However, rpm-ostree does support nondestrucive parallel installation inside existing roots)
How To Test
- Use rpm-ostree compose tree to commit a set of RPMs to an OSTree repository
- Point the client system at it using "ostree remote add" and "rpm-ostree rebase".
User Experience
For systems which are deployed using this model, the user experience difference is very large. The traditional package managers such as "yum", if installed, can only operate in a read-only mode.
Dependencies
The rpm-ostree tooling depends on and intends to integrate with other fundamental Fedora components such as Anaconda. It makes use of the new hawkey library which is a component underlying dnf.
Contingency Plan
If there are issues with rpm-ostree, the traditional package system continues as before.
- Blocks release? Unknown
- Blocks product? Fedora Atomic
Documentation
https://github.com/projectatomic/rpm-ostree