From Fedora Project Wiki
 
(39 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{admon/important | Comments and Explanations | 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.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}


<!-- Self Contained or System Wide Change Proposal?
<!-- Self Contained or System Wide Change Proposal?
Line 27: Line 26:


== Summary ==
== Summary ==
A variant of Fedora Workstation that uses OSTree to install and and update the OS
A variant of Fedora Workstation that uses OSTree to install and update the OS


== Owner ==
== Owners ==
<!--  
<!--  
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.  
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.  
This should link to your home wiki page so we know who you are.  
This should link to your home wiki page so we know who you are.  
-->
-->
* Name: [[User:MatthiasClasen| Matthias Clasen]]
* Name: [[User:MatthiasClasen| Matthias Clasen]], Owen Taylor, Alex Larsson, Richard Hughes, David King
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: mclasen@redhat.com
* Email: mclasen@redhat.com
Line 56: Line 55:
-->
-->
* 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]]
Status update from [[https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/thread/6N4VC2BXCVIRVB4UURO2L4MNQGKYJJKH/ | April 7]]
Status update from [[https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/thread/SPMFH74DXGOJRQ6JVDXKJSZRCQ44PN2S/ | May 17]]


== Detailed Description ==
== Detailed Description ==


<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
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 ==
== Benefit to Fedora ==


Updating the operating system via ostree has multiple advantages compared to traditional yum or dnf updates:
 
 
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->
* 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 ==
== Scope ==
* Proposal owners:
* '''Proposal owners:'''
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
** Create rpm-ostree repositories with the workstation content (Done: David)
*** configs are here: https://pagure.io/workstation-ostree-config/commits/master
*** temporary hosting for repos: http://209.132.179.147/repo
** Provide a solution for the initial install of an ostree-based workstation (in progress: David)
*** see http://www.projectatomic.io/docs/fedora_atomic_bare_metal_installation/
*** see https://fedorahosted.org/rel-eng/ticket/6119
** gnome-software: Support using rpm-ostreed for system updates in an ostree-based installation (in progress: Richard)
*** 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
** Work with rel-eng team to enable building xdg-apps in koji (Owen)
*** 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


* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* '''Release engineering:'''
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
** Ostree-related deliverables:
*** Tooling for building workstation rpm-ostree repositories (share with project atomic ?)
**** see http://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-tooling/backlog?tags=atomic_redesign
*** Host workstation rpm-ostree repository (share with project atomic ?)
*** Update repository as updates appear in the yum repository they're based on (once-per-day is sufficient)
*** Build x86_64 installer iso's for major milestones (beta, ga)
*** Ticket for this part: https://fedorahosted.org/rel-eng/ticket/6399
** xdg-app related deliverables:
*** Tooling for building xdg-apps in Fedora: https://fedoraproject.org/wiki/Workstation/BuildingXdgApps
*** Hosting for xdg-apps in Fedora


* Release engineering: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.-->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here.
Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.-->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->


* Policies and guidelines: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* '''Policies and guidelines'''
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
** The third-party software guidelines are needed


* Trademark approval: N/A (not needed for this Change)
* '''Trademark approval:''' N/A (not needed for this Change)
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->


Line 89: Line 140:
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
This will be a separate variant of the Fedora workstation product, 'traditional' rpm-based installation will continue to be supported.
N/A (not a System Wide Change)
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 ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.


Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
The content of the OSTree image is going to be basically identical to the 'traditional' workstation install, it is just installed and updated differently.
Therefore, the existing tests for the workstation will apply and ensure that the overall functionality of the OS, the desktop and the applications.


A good "how to test" should answer these four questions:
Testing for this particular to this change should focus on the areas of difference:


0. What special hardware / data / etc. is needed (if any)?
* Does the installer work ?
1. How do I prepare my system to test this change? What packages
* Does gnome-initial setup come up on first boot, and does it work ?
need to be installed, config files edited, etc.?
* Can the installed system be updated from the ostree repo using the rpm-ostree commandline tool ?
2. What specific actions do I perform to check that the change is
* Can the installed system be updated using gnome-software ?
working like it's supposed to?
* Are system configuration changes preserved across updates ?
3. What are the expected results of those actions?
* Does gnome-software correctly reflect the fact that the system is readonly ?
-->
* Does gnome-software offer to install and remove xdg-apps ?
* Can xdg-apps be updated 'live', without reboot ?


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
== User Experience ==
N/A (not a System Wide Change)


== User Experience ==
In an OStree-based installation, updates of the OS require a reboot (as offline updates do currently), but we no longer reboot twice, since the updated images can be downloaded and deployed while the system is running, and then we can directly reboot into the new image. Since the OS image is readonly, installing rpms does not work (at least not until rpm-ostree's layering capability is mature enough for production). Desktop application can be installed in the form of xdg-apps, which are independent from the OS image and can be updated 'live'.
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)  


== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
This change depends on the rpm-ostree tooling and infrastructure that is developed as part of project Atomic, and on xdg-app tooling and infrastructure.
N/A (not a System Wide Change)


== Contingency Plan ==
== Contingency Plan ==


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: This feature is about a new deliverable, so if we don't make it, we will just not add the new product variant to our portfolio for Fedora 25. This will affect the website and release announcement, but little else. The ostree support in gnome-software will just be inactive as it is on traditional installs, anyway.
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: Beta
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Blocks release: No, the image-based installation will be experimental in Fedora 25, and it would not be appropriate for it to block the release.
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->


== Documentation ==
== Documentation ==

Latest revision as of 14:04, 20 October 2016



OSTree-based Workstation

Summary

A variant of Fedora Workstation that uses OSTree to install 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-10-20
  • Tracker bug: <will be assigned by the Wrangler>

Status update from [| April 1]

Status update from [| April 7]

Status update from [| May 17]

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

  • Other developers:
    • Create a fedora-release subpackage for this workstation variant
    • Support installing non xdg-app content using rpm-ostree
  • 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

The content of the OSTree image is going to be basically identical to the 'traditional' workstation install, it is just installed and updated differently. Therefore, the existing tests for the workstation will apply and ensure that the overall functionality of the OS, the desktop and the applications.

Testing for this particular to this change should focus on the areas of difference:

  • Does the installer work ?
  • Does gnome-initial setup come up on first boot, and does it work ?
  • Can the installed system be updated from the ostree repo using the rpm-ostree commandline tool ?
  • Can the installed system be updated using gnome-software ?
  • Are system configuration changes preserved across updates ?
  • Does gnome-software correctly reflect the fact that the system is readonly ?
  • Does gnome-software offer to install and remove xdg-apps ?
  • Can xdg-apps be updated 'live', without reboot ?

User Experience

In an OStree-based installation, updates of the OS require a reboot (as offline updates do currently), but we no longer reboot twice, since the updated images can be downloaded and deployed while the system is running, and then we can directly reboot into the new image. Since the OS image is readonly, installing rpms does not work (at least not until rpm-ostree's layering capability is mature enough for production). Desktop application can be installed in the form of xdg-apps, which are independent from the OS image and can be updated 'live'.

Dependencies

This change depends on the rpm-ostree tooling and infrastructure that is developed as part of project Atomic, and on xdg-app tooling and infrastructure.

Contingency Plan

  • Contingency mechanism: This feature is about a new deliverable, so if we don't make it, we will just not add the new product variant to our portfolio for Fedora 25. This will affect the website and release announcement, but little else. The ostree support in gnome-software will just be inactive as it is on traditional installs, anyway.
  • Contingency deadline: Beta
  • Blocks release: No, the image-based installation will be experimental in Fedora 25, and it would not be appropriate for it to block the release.

Documentation

N/A (not a System Wide Change)

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/WorkstationOstree&oldid=477617"