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-do...
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...
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/msg0015...
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 =)