|
|
| (9 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. |
| | |
| | = Current status = |
| | |
| | See [https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/message/JDBGLC2MCXWPHAPULN6PKUKFRE2SS7GT/ this post] for links |
| | to an installer ISO. |
|
| |
|
| == Advantages == | | == Advantages == |
|
| |
|
| Updating the operating system via ostree has multiple advantages compared to traditional yum or dnf updates:
| | 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''. |
|
| |
|
| * 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.
| | Moving desktop applications into Flatpak brings stronger isolation, and solves |
| * 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
| | very longstanding issues with using yum/dnf for desktop applications, such as the |
| * The update can be rolled back if the new operating system is incompatible with the users hardware or applications
| | 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). |
|
| |
|
| 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.
| | 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. |
|
| |
|
| * 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.
| | '''oc cluster up''' allows developers to test server applications locally with ease, and then |
| * 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.
| | push them to production Kubernetes/OpenShift clusters. |
| * 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. | | 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 == | | == Use cases == |
|
| |
|
| 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. | | 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. |
|
| |
| == Installing applications ==
| |
|
| |
| Graphical applications such as productivity applications or games 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.
| |
| [https://lists.fedoraproject.org/pipermail/desktop/2015-May/012362.html introduction] [https://lists.fedoraproject.org/pipermail/desktop/2015-June/012468.html update]
| |
|
| |
| There are some classes of things that a user might want to install that are not applications: for example: fonts, codecs, and proprietary kernel modules. These will require a different installation mechanism.
| |
|
| |
| It is important that even if there are different underlying technologies, the user experience is seamless: that the user doesn't have one experience with system updates, another experience with applications, and yet another with fonts. We expect to pull everything together in GNOME Software.
| |
|
| |
| == Developer Scenarios ==
| |
|
| |
| 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:
| |
|
| |
| * 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 their application
| |
| * A developer using Java for a server application
| |
| ** An IDE
| |
| * A Fedora developer
| |
| ** dependencies of a packages that they want to build locally
| |
| ** A package that they built
| |
| * A kernel developer
| |
| ** Tools required by the kernel build system
| |
| ** A kernel they just built
| |
|
| |
| 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 ==
| |
|
| |
| It's unlikely that any single approach can replace all situations where someone would install an RPM on a Fedora system to do a development task. Some things that could be on the menu of options:
| |
|
| |
| === Home directory installation ===
| |
|
| |
| Developers often already work without modifying the system: examples include GNOME's [https://developer.gnome.org/jhbuild/ jhbuild] and Python's virtualenv. For a Java developer, the normal workflow is that JAR files live within your development tree and are not installed systemwide. All these cases work perfectly within the "Atomic" model.
| |
|
| |
| === Installing tools as applications ===
| |
|
| |
| Some tools, such as an IDE make sense to install the same way as other applications. Because IDE's are typically large and cross-platform, it may be hard to get them modified to work well within a sandbox system - they might need permissions like "access all files in the users home directory. This doesn't cause any problem for the question of software installation and layering, but does pose an issue for us in terms of how we present application installation to the user: how can you allow the user to easily install Eclipse and simultaneously protect the user from being tricked into installing a trojan that steals credit card data. Perhaps unsandboxed apps, or apps with dangerous permissions are only allowed to be installed from trusted repositories.
| |
|
| |
| === Layering packages ===
| |
|
| |
| 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. If the package consists only of new files, it may be possible to pull the files into the running system (See http://blog.verbum.org/2014/02/26/ostree-rigorous-and-reliable-deployment/ for some related discussion.)
| |
| Having to reboot to install a development header is likely unacceptable, so it seems like this idea of pulling in new files into the running system is essential for this to be useful.
| |
|
| |
| There also has to be a large degree of robustness - it must be clear to the user what packages can be installed in this fashion and installing has to be reliable. Trying to install packages without upgrading existing packages in current Fedora tends to work very badly because of the degree of flux in the repositories - it's common to have <package>-<version>-<rev> installed, but only <package>-<version>-<rev+1> in the repository.
| |
|
| |
| The effect on updates and upgrades also needs to be carefully considered - packages that have been layered on top of the core operating system can't be allowed to break an update for a security/bug fix or an upgrade to a newer version of Fedora.
| |
|
| |
| === Using Containers ===
| |
|
| |
| 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.
| |
|
| |
| === Using a nested operating system ===
| |
|
| |
| The easiest way to handle presenting an environment that looks like a classic Fedora system where you can <code>dnf install</code> arbitrary packages is to have a nested operating system file system that's separate from the host operating system. This could be done with containers or virtual machines. If we went this route, there might be an argument that using Vagrant is a superior route than building something new and different. All the documentation and experience with people doing Linux development in an OS X or Windows desktop would carry over. The basic question with using Vagrant from a marketing perspective: 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.
| |
|
| |
|
| == Work Items == | | == Work Items == |
|
| |
|
| === Basics === | | === Basics === |
| * An ostree tree for Fedora Workstation, constructed using rpm-ostree; this should be an regular output of the Fedora releng infrastructure | | * 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 | | ** see http://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-tooling/backlog?tags=atomic_redesign |
| * An installation solution. There is Anaconda support used by Fedora Atomic Host
| |
| ** see http://www.projectatomic.io/docs/fedora_atomic_bare_metal_installation/
| |
| ** see https://fedorahosted.org/rel-eng/ticket/6119
| |
| * GNOME Software support for rpm-ostree upgrades | | * 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 | | ** This will basically replace the "System updates" line in the updates list. Need to figure out where to get metadata |
| ** Cockpit already has support for atomic updates, should compare what they do | | * Better support for using Docker/OCI containers as "pet shells" |
| | | * Automatically convert RPM packages into flatpak |
| === xdg-app ecosystem ===
| |
| * Versioned releases of GNOME (and other?) runtimes
| |
| * A SDK that accompanies the runtime to be used for building applications
| |
| * Secure sandboxing. This requires Wayland, and probably kdbus. Wayland is happening for F24. kdbus, not.
| |
| * A versioned, defined, portal definition, which forms the basis of xdg-app interoperability between different distributions and desktops
| |
| * A way of finding xdg-apps with more defense against malware
| |
| * GNOME Software support for installing xdg-apps. This will be available in F24
| |
| | |
| === Developer enhancements ===
| |
| * An IDE with integrated support xdg-app creation - perhaps GNOME Builder
| |
| * A GUI for Docker containers
| |
| ** cockpit has basic support - what are the future plans? | |
| ** kitematic is portable to Linux, but a challenge to package (uses the Chromium based web runtime from the Atom editor, along with a huge pile of node modules)
| |
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
- An ostree repo/branch for Fedora Workstation, constructed using rpm-ostree; this should be an regular output of the Fedora releng infrastructure
- 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
