From Fedora Project Wiki
(25 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
= Atomic Workstation =
 
= Atomic Workstation =
  
The idea of an "Atomic 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.
+
The idea of an "Atomic Workstation" is to use the ideas of "Project Atomic" to have a core operating system for a desktop/workstation that updates atomically as a whole. Desktop applications are Flatpaks.  Local server application development happens primarily in [https://github.com/openshift/origin/blob/master/docs/cluster_up_down.md oc cluster up].  We also encourage use of "pet" containers via Docker or related tools.
  
== Advantages ==
+
= Current status =
  
The basic advantage of the atomic model is enhanced reliability:
+
See [https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/message/JDBGLC2MCXWPHAPULN6PKUKFRE2SS7GT/ this post] for links
 +
to an installer ISO.
  
* Reliable and consistent upgrades between versions - F22 is the same as F21-upgraded
+
== Advantages ==
* Testing that is done tests the actual operating system that is on users machines; there are not thousands of different variants in the wild.
 
* There is no possibility that an upgrade of the operating system runs into problems halfway through and leaves the system in a trashed state.
 
* It is possible to rollback from unsuccessful updates, or if new operating system doesn't work with the user's apps
 
  
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.
+
The use of rpm-ostree for the core OS brings fully atomic upgrades. Because rpm-ostree is
 +
a hybrid image/package system, it's also possible to layer RPMs for desktop applications
 +
which aren't yet Flatpaks, and "OS extensions" such as ''powerline'' and ''ykclient''.
  
== Use cases ==
+
Moving desktop applications into Flatpak brings stronger isolation, and solves
 +
very longstanding issues with using yum/dnf for desktop applications, such as the
 +
fact that upgrading deletes the files underneath the running application and
 +
often breaks it.  (And we don't want most desktop applications in the base ostree stream,
 +
since it's more for the "base OS" which goes along with a kernel which requires a reboot).
  
Pretty much anything that the normal [[Workstation/Workstation_PRD|Workstation]] is used for. The primary target of the Workstation is different varieties of developer, but the Workstation is also supposed to work for other users such as sysadmins, people who want to play games, or people who only want to use productivity applications.
+
One important note: We are focusing here on Flatpak for isolation - we expect to auto-convert
 +
packaged RPMs in Fedora into Flatpak, rather than relying primarily on the "3rd party repository"
 +
model.
  
== Installing applications ==
+
'''oc cluster up''' allows developers to test server applications locally with ease, and then
 +
push them to production Kubernetes/OpenShift clusters.
  
Applications are installed via [https://github.com/alexlarsson/xdg-app xdg-app]. If we provide a "fedora runtime", we can rebuild Fedora RPMs into applications in a pretty transparent fashion.
+
Many developers want random utilities which aren't server apps or desktop apps, such as
[https://lists.fedoraproject.org/pipermail/desktop/2015-May/012362.html introduction] [https://lists.fedoraproject.org/pipermail/desktop/2015-June/012468.html update]
+
'''ansible''' for example. We encourage running "pet" containers for these where one
 +
uses tools like dnf or pip. We should have a specialized desktop terminal application that makes it easy to create/manage
 +
these "pet" containers - similar to virt-manager.
  
== Developer Scenarios ==
+
== Use cases ==
  
The Fedora Workstation image might have some set of developer tools installed natively - at least a compiler. But the set of things that a developer might need is far too large to have *everything* part of the operating system. Some examples of what a developer might normally install on a Fedora system:
+
Pretty much anything that the normal [[Workstation/Workstation_PRD|Workstation]] is used for. The primary target of the Workstation is different varieties of developer, but the Workstation is also supposed to work for other users such as sysadmins, people who want to play games, or people who only want to use productivity applications.
 
 
* A developer of a native Linux GUI or command line application:
 
** library header files
 
** tools for compilation like automake or a compiler for a different language
 
** tools for debugging like gdb or valgrind
 
* A developer using Python or Ruby for a web application
 
** modules for the interpreted language
 
** Server components like mysql or httpd to test there application
 
* A developer using Java for a server application
 
** An IDE
 
 
 
Kernel developers are an outspoken and important target for Fedora, but one that is numerically small. Testing a new kernel on bare hardware is inherently tricky, because it is in fact changing the operating system, not testing something on top of the operating system. At least a logical possibility is to have explicit ostree/rpm-ostree support in the kernel build system: a 'make ostree' command would build a new ostree tree based on the current tree plus a commit for the new kernel.
 
 
 
== Addressing developer needs ==
 
 
 
https://github.com/projectatomic/rpm-ostree/pull/107/commits is a prototype of how layering packages of an rpm-ostree works - it creates a new tree locally with the specified packages layered on top. This is not necessarily very useful for solving the problem of a developer wanting to install a few packages locally.
 
 
 
* It compromises the idea that we test the same core operating system as the user is running
 
* It compromises the idea that upgrades cannot break, it's possible that the core operating system plus a set of layered RPMs will hit dependency conflicts if we try to reproduce it on a newer version of Fedora, so the user might need to debug problems with the layered RPMs in order to install an operating system update.
 
* Installing new packages will require a reboot into a new operating system, this is unlikely to be considered acceptable when installing a development header.
 
 
 
Doing development in containers is one better way to handle these sorts of scenarios. Containers are great for testing: they allow installation of dependencies without conflicts, and also allow creating a container image that can be deployed *exactly as is*, without worrying about whether the deployment operating system is the same as the development system. Containers can also be used for compilation, although this is currently less common. Compiling in a container gives a very straightforward way to build binaries that are independent of the developer's system; that use a standard compiler and library versions. ([https://wiki.gnome.org/Projects/GnomeContinuous gnome-continuous] is an example of a system that uses containerization in this way.) Compiling against a standard SDK in a container makes even more sense when the build target is an application that will be run in a container.
 
 
 
When the user is using an IDE, it's the IDE's responsibility to make working with containers as transparent and convenient as possible.
 
  
The main, and strong, disadvantage of pushing development towards containers is one of consistency with the workflows that developers are used to, and with the documentation that is available out there. If someone finds a tutorial on the internet about how to develop with Django and mysql with Fedora, that tutorial isn't going to work at all if we are asking them to create a Docker image.
+
== Work Items ==
  
Perhaps it would be possible to use container-like technology to allow working within a Fedora-image that is separate from the main operating system, and where it is simply possible to <code>dnf install</code> packages. But at that point, would it be better to just point people to using Vagrant, so that all the documentation and experience with people doing Linux development in an OS X or Windows desktop would carry over? This approach is likely to be controversial: how are we a better development environment for deployment on Linux if developers are working the same way they would on a different operating system.
+
=== Basics ===
 +
* An ostree repo/branch for Fedora Workstation, constructed using rpm-ostree; this should be an regular output of the Fedora releng infrastructure
 +
** see http://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-tooling/backlog?tags=atomic_redesign
 +
* GNOME Software support for rpm-ostree upgrades
 +
** This will basically replace the "System updates" line in the updates list. Need to figure out where to get metadata
 +
* Better support for using Docker/OCI containers as "pet shells"
 +
* Automatically convert RPM packages into flatpak

Revision as of 14:08, 25 February 2017

Atomic Workstation

The idea of an "Atomic Workstation" is to use the ideas of "Project Atomic" to have a core operating system for a desktop/workstation that updates atomically as a whole. Desktop applications are Flatpaks. Local server application development happens primarily in oc cluster up. We also encourage use of "pet" containers via Docker or related tools.

Current status

See this post for links to an installer ISO.

Advantages

The use of rpm-ostree for the core OS brings fully atomic upgrades. Because rpm-ostree is a hybrid image/package system, it's also possible to layer RPMs for desktop applications which aren't yet Flatpaks, and "OS extensions" such as powerline and ykclient.

Moving desktop applications into Flatpak brings stronger isolation, and solves very longstanding issues with using yum/dnf for desktop applications, such as the fact that upgrading deletes the files underneath the running application and often breaks it. (And we don't want most desktop applications in the base ostree stream, since it's more for the "base OS" which goes along with a kernel which requires a reboot).

One important note: We are focusing here on Flatpak for isolation - we expect to auto-convert packaged RPMs in Fedora into Flatpak, rather than relying primarily on the "3rd party repository" model.

oc cluster up allows developers to test server applications locally with ease, and then push them to production Kubernetes/OpenShift clusters.

Many developers want random utilities which aren't server apps or desktop apps, such as ansible for example. We encourage running "pet" containers for these where one uses tools like dnf or pip. We should have a specialized desktop terminal application that makes it easy to create/manage these "pet" containers - similar to virt-manager.

Use cases

Pretty much anything that the normal Workstation is used for. The primary target of the Workstation is different varieties of developer, but the Workstation is also supposed to work for other users such as sysadmins, people who want to play games, or people who only want to use productivity applications.

Work Items

Basics