(→Scope) |
|||
| Line 56: | Line 56: | ||
--> | --> | ||
* Tracker bug: <will be assigned by the Wrangler> | * Tracker bug: <will be assigned by the Wrangler> | ||
Status update from [[https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/thread/45L3Q6RMFNNH2R4YAIMPEVXZBSBQILSZ/ | April 1]] | |||
== Detailed Description == | == Detailed Description == | ||
Revision as of 18:05, 1 April 2016
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.
OSTree-based Workstation
Summary
A variant of Fedora Workstation that uses OSTree to install and and update the OS
Owners
- Name: Matthias Clasen, Owen Taylor, Alex Larsson, Richard Hughes, David King
- Email: mclasen@redhat.com
- Release notes owner:
- Product: Fedora Workstation
- Responsible WG: Workstation working group
Current status
- Targeted release: Fedora 25
- Last updated: 2016-04-01
- Tracker bug: <will be assigned by the Wrangler>
Status update from [| April 1]
Detailed Description
The idea of an image-based workstation is to use the ideas of "Project Atomic" to have a core operating system for a workstation that updates atomically as a whole, and then layer extra software on top of that. This is as opposed to the traditional model, where the operating system is dynamically composed on the end users system out of individual packages.
For a longer discussion, see Workstation/AtomicWorkstation.
Benefit to Fedora
Updating the operating system via ostree has multiple advantages compared to traditional yum or dnf updates:
- The update is offline, and there is no possibility of the running system being in a mixed state with some applications still using old versions and some using new versions. This has already been accomplished using PackageKit offline updates in recent Fedora.
- The update is reliable and atomic - there is no complicated process of updating files piecemeal that can break in the middle, or be interrupted by power failure and leave the system in an inconsistent and broken state
- The update can be rolled back if the new operating system is incompatible with the users hardware or applications
Advantages that we get beyond this come from improving the separation between the operating system and what the user has installed on top of it; if we package software as xdg-app bundles depending on a standard runtime or as Docker containers, then we expect them to have little ability to break the operation of the underlying system, and we expect them to also be insulated from changes in the underlying system, and not be dependent on specific versions of packages and libraries.
- Currently, what we provide for each update or upgrade is a set of package metadata and an algorithm and we expect it to work for all combinations of packages a user might have installed, including potentially packages not even from Fedora's repositories. The dnf and yum algorithms are impressive, and *usually* they get this right. But sometimes they don't - often because there's no obvious right thing to do. And in these cases, the system requires an experienced sysadmin to debug. If we precisely define the operating system, there are not uncountable numbers of possible upgrades, instead there is precisely one upgrade between each set of Fedora versions.
- We can potentially do a better job at functionality testing as well, because each Fedora Workstation user's system will be more alike and more like what is tested.
- Because the operating system is precisely defined, we can remove components from it; currently we have no idea whether a package on the system is part of the operating system or something the user installed.
- The components that are installed on top of the operating system are potentially more portable between different versions of Fedora and even between different distributions.
Note: Currently, many problems with an unbootable Fedora system are bootloader or initrd issues; bootloader configuration issues are still a potential problem with the Atomic model. The ostree handling of /etc, which allows arbitrary modification by the user, also means that there is a gap between the goal of an unbreakable system and the reality.
Scope
- Proposal owners:
- Create rpm-ostree repositories with the workstation content (in progress: David King)
- Provide a solution for the initial install of an ostree-based workstation
- gnome-software: Support using rpm-ostreed for system updates in an ostree-based installation (in progress: Richard Hughes)
- see Cockpit code: https://github.com/cockpit-project/cockpit/blob/master/pkg/ostree/client.js
- see rpm-ostreed code: https://github.com/projectatomic/rpm-ostree/tree/master/src/daemon
- gnome-software: Support installing and updating xdg-apps (initial support DONE)
- gnome-software: Support managing xdg-app repositories
- xdg-app: support remote management, similar to what rpm-ostree does
- xdg-app: provide a daemon for system-wide xdg-app installation
- look at Endless' daemon for this purpose (Alex)
- xdg-app: Support appstream data in repositories (DONE)
- xdg-app: Figure out ways to integrate with rel-eng infrastructure for containers and ostree repos
- Investigate producing oci bundles as primary artifacts (Alex)
- Investigate skopeo to import oci bundles into ostree repos (Owen)
- Create an initial set of xdg-app repositories to include in the fedora-workstation-repositories package
- Wayland-related tasks
- Make per-app xwayland possible for X apps
- Kill abstract sockets that are problematic for sandboxing: X, dbus, ...
- Other developers:
- Create a fedora-release subpackage for this workstation variant
- Support installing non xdg-app content using rpm-ostree
- Release engineering:
- Tooling for building workstation rpm-ostree repositories (share with project atomic ?)
- Host workstation rpm-ostree repositories (share with project atomic ?)
- Tooling for building xdg-apps in Fedora
- Hosting for xdg-apps in Fedora
- List of deliverables: N/A (not a System Wide Change)
- Policies and guidelines
- The third-party software guidelines are needed
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
This will be a separate variant of the Fedora workstation product, 'traditional' rpm-based installation will continue to be supported. Switching to the ostree variant will be an explicit decision for the user to make before installing. We will not support switching from one variant to the other during an upgrade.
How To Test
TBD
User Experience
N/A (not a System Wide Change)
Dependencies
N/A (not a System Wide Change)
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
- Blocks product? product
Documentation
N/A (not a System Wide Change)