From Fedora Project Wiki
mNo edit summary
 
(29 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{admon/warning|Project Atomic is now sunset|As of 2020, the Atomic Workstation is dormant and has been for some time. The content of this page and others related to Atomic are preserved for historical reference and because some of the content is still useful and relevant, but the group is not active or holding meetings. Fedora Silverblue is the replacement for Atomic Workstation.}}
= 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 -the
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 for the project tests the actual operating system that is on users machines
* There is no possibility that an upgrade of the operating system runs into problems halfway through and leaves the system in a trashed state.
* Can 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.
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
== Development ==
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.


The primary target of Fedora Workstation is different types of developers, and currently developers often install things that don't fit well into the application model: they install daemons like web servers and databases to test apps they are developing locally. They install developer headers. They install modules for interpreted languages like Python or Ruby. And they install developer tools like gdb or valgrind.
== Use cases ==
 
Doing development in containers is one way to handle these sorts of scenarios. Ideally integration between IDE and container systems could make this very transparent to developers.


But pushing all development towards containers can reduce the extent that existing documentation is useful on Fedora.
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.


== Layering on arbitrary RPMS ==
== Work Items ==


https://github.com/projectatomic/rpm-ostree/pull/107/commits is a prototype of how layering packages of an rpm-ostree works - this seems to create a new tree locally with the specified packages layered on top, which is not necessarily useful for the developer usecase, since rebooting to install new devel headers or tools is not going to be attractive to users at all.
=== 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

Latest revision as of 17:37, 4 November 2021

Project Atomic is now sunset
As of 2020, the Atomic Workstation is dormant and has been for some time. The content of this page and others related to Atomic are preserved for historical reference and because some of the content is still useful and relevant, but the group is not active or holding meetings. Fedora Silverblue is the replacement for 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 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