Atomic workstation

[Colin Walters]

On Wed, Dec 3, 2014, at 02:22 PM, Matthias Clasen wrote:
> Hi Colin,
> 
> I wondered what your thoughts are about the possibility of serving the
> workstation image as a tree in Fedora atomic.

The TL;DR on this is that rpm-ostree would be extremely disruptive.  I believe the technology is worth the benefit of that pain, but realistically until its feature set enhances, I suspect most users would want to stick with traditional package manager tradeoffs.

Longer answer:

Currently rpm-ostree is focused on use in the Project Atomic context, when paired with Docker/Kubernetes.

However, before that happened, this was an initial goal of the rpm-ostree project, and you see that reflected in the branch names:

fedora-atomic/rawhide/x86_64/docker-host

Where the last bit of "docker-host" is a *name* for a set of packages, here:
https://git.fedorahosted.org/cgit/fedora-atomic.git/tree/fedora-atomic-docker-host.json

It's quite easy in fact to make a workstation tree, that would appear as 

fedora-atomic/rawhide/x86_64/workstation 

> It would be interesting for the atomic update and rollback capabilities
> that ostree offers. 

Right, but for the Workstation use case this runs quickly up against the
fact that the tree is immutable locally.  See
 https://github.com/cgwalters/atomic-pkglayer
for some prototype work there.

Furthermore specifically for workstation, PackageKit has no support for it.  I imagine it could learn, but it would be quite a challenge.  Once rpm-ostree supports partial live updates, to accurately represent the situation PackageKit would have to learn about the fact that there can be multiple "states" active at one time (each with their own RPM database).

Of course this "multiple states" scenario happens *today* with yum - not all processes get restarted on update, but it's ignored by default by yum/dnf, and PackageKit has some historical attempts but AFAIK it currently doesn't try by default. 

There are later tools which try to partially reconstruct this, like:
http://dnf-plugins-core.readthedocs.org/en/latest/needs_restarting.html
http://rwmj.wordpress.com/2014/07/10/which-services-need-restarting-after-an-upgrade/

In an rpm-ostree world this would become significantly more important because unless an update could be *proven* to apply safely live, an "rpm-ostree upgrade $package" would queue the change for the *next* boot.  Notable values of $package here would include every running desktop app.  This model would then show where we really need to go is coordination with Software/desktop UI to help close down apps, update them while they're not running (greying out the start icons again), and then allow starting.

> Maybe we could also use it for doing similar testing
> to the upstream gnome-continuous, using taskotron.

This is a whole other thread and a very complex, multifaceted topic.  Some brief points here:

Fedora releng investment
----

Having worked on the Project Atomic image for Fedora 21, I can say that there need to be more people in Fedora rel-eng, and some focused investment on improving iteration cycles there.  I think if that team figured out how to allow contributions and decoupled component releases, it would allow sub-groups to take more ownership of their deliverables.

There's no reason the workstation images should be "nightly" - just make them continuously.

Server side rollback
----

To me, this is the most compelling feature of (rpm-)ostree, far more than atomic upgrades.  The fact that it does not care about the version numbers and allows the release-engineering side to revert means that it's much easier to have a continuously *functional* system, to whatever degree desired.  I touch on that here:
https://mail.gnome.org/archives/desktop-devel-list/2014-September/msg00152.html

It unlocks the ability to do continuous delivery.

Continuous-style delivery would by far be the most radical change, affecting everything between RPM, fedpkg and Koji.   And changing RPM is *hard* - it's like trying to change the bottom block in a Jenga tower.

A baby step here would be nvestigating a "distro-sync by default" change for dnf.  Maybe on a per-repository basis.  (This would be another thing PackageKit would have to represent in the UI)

Installed tests
----

https://wiki.gnome.org/GnomeGoals/InstalledTests would be worth pursuing, particularly if beefed up with support for non-desktop tests.  Think random Python libraries or the like.

Well there's more here but this email is already long, and enough to talk about =)