For the last few Fedora releases, the Workstation WG has been working on combining the best of the Project Atomic pattern with the Fedora Workstation Edition into a deliverable dubbed “Fedora Atomic Workstation”. In Fedora 27, we have reached a point where we feel comfortable inviting other developers and enthusiasts to try it out and even make it their daily driver.
Read on to discover what Fedora Atomic Workstation is, what its benefits are, and how you can get started today!
What is Atomic Workstation?
Just like Atomic Host, Atomic Workstation uses RPM-OSTree as its update manager. However, Atomic Workstation is geared towards all the same use cases that the regular Workstation Edition is meant to fulfill. Though there are some differences between the two beyond the update model.
In an Atomic Workstation, desktop applications are shipped and run as
flatpaks, and development mostly happens inside
containers. For example, you may have a pet container with your development
environment set up as well as an
oc cluster up OpenShift cluster to develop
Why should I use Atomic Workstation?
So what are the advantages of this strategy? Many of the reasons below are shared with Atomic Host. Though I will try to give a more Workstation-centric point-of-view.
1. Transactional Updates
The main reason to use Atomic Workstation of course is transactional updates. This is as relevant in the server case as it is for desktops. Most people would consider their workstations to be the stereotypical pet system: set up and customized just the way they want them, and a huge hindrance to productivity if anything should happen to them. Using an update model which greatly reduces risks of failures is thus well justified.
I will not stay on this subject any longer since I assume readers of this blog are familiar with the benefits there and what pitfalls the Atomic model helps us avoid. If you are not familiar with these ideas, definitely check out the OSTree docs and the Project Atomic update docs if you’d like more information.
2. Immutability and Isolation
As discussed in
a previous blog entry,
all the great features of an OSTree-based system require immutability of the
base OS. For example,
/usr is not writable by default. This is equally true
in Atomic Workstation as it is in Atomic Host. This is a good thing, because
(1) it protects you from
and (2) it encourages a healthier workflow.
For example, on
yum/dnf-managed systems, RPM scriptlets run unconfined
as root during update transactions, which opens the door for accidental (or
intentional) corruption. On
rpm-ostree-managed systems, all scriptlets are run
on the server when composing the update. (As mentioned lower down, we do also
support layering additional RPMs; their scriptlets are run in a locked down
container and cannot affect the running system).
By running your applications in flatpaks and doing your development in containers, you not only help protect your base OS from harm but also minimize the number of packages standing between you and a successful boot.
Basing your development workflow around pet containers could warrant a blog post of its own. There have been some great talks around that area at DevConf.cz this year (linked below).
3. Effortless Change Tracking
Now, part of customizing your workstation will undoubtedly require installing
packages that are not part of the base OSTree and aren’t quite fit for
containerization (e.g. drivers, virtualization stacks,
Because RPM-OSTree is a hybrid model, it understands both RPMs and OSTrees.
We can, for example, do
rpm-ostree install vim-enhanced libvirt-client to
layer additional packages.
rpm-ostree status will then show:
$ rpm-ostree status
Version: 27.62 (2018-01-31 21:39:54)
GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4
LayeredPackages: libvirt-client vim-enhanced
In contrast to
dnf/yum-managed systems, which provide a “bag of
rpm-ostree status allows to know exactly what we
changed from the base OSTree commit, and how to go back to the initial state (in
rpm-ostree uninstall libvirt-client vim-enhanced).
For completeness, I will mention that RPM-OSTree not only supports pure
additions, but also replacing and removing base packages. All these changes
can equally be tracked in
rpm-ostree status and easily reverted.
Additionally, because in the OSTree model configuration defaults are stored in
/usr/etc, one can also perform a simple diff to figure out which defaults were
diff /usr/etc /etc | less).
4. Upstream Testing
Having updates delivered as concrete units allows the content provider to more easily test them, which translates into a more stable operating system for end users. In contrast, it’s effectively impossible in the “bag of packages” approach to sanely test all permutations. This mostly means that testing is limited to the package-level.
In an OSTree model however, it’s possible to gate updates on higher-level integration tests such as what we’ve been doing in the two-week releases of Fedora Atomic Host. Note though that Atomic Workstation updates are not currently being gated on tests; we are still at the onset of these discussions.
5. Automatic Updates
In RPM-OSTree, we are currently working on adding an
automatic update feature.
Similar functionality on
dnf-managed systems does
exist. The difference is that the
OSTree model allows us to eliminate or minimize
many of the issues
involved in such a scheme. For example, the ability to roll back updates is
critical here, and this is something that RPM-OSTree does with ease.
In the future, we’d like to get to a point where (if enabled) the system
automatically prepares updates in the background and
upgrading simply involves
rebooting your computer for minimal downtime.
How can I get started with Atomic Workstation?
You can either
download the ISO
and re-install from scratch, or you can convert your existing
using the steps from
document. The latter also allows you to switch back and forth between the two
models if you’re not yet ready to dive in.
If you need any help, you can pop into the
freenode/#atomic channel, or send
an email to the