Atomic Workstation next steps
I had a long discussion yesterday with Colin about some of the pain
points that are causing him to currently have a separate atomic-
workstation build on the Centos infrastructure, and what we can do to
address those and consolidate back to the Fedora infrastructure.
The long term goal we have is getting to the point where someone who is
moderately adventuresome can consume Fedora Atomic Workstation in a
rolling fashion - every week a new version of Atomic Workstation shows
up with whatever minor or major updates are considered stable, and if
something breaks, rpm-ostree offers the ability to roll back.
For Atomic Host, they offer this experience based on the *last* stable
release of Fedora - so when a new release of OpenShift or atomic-cli
happens, they rebase it in f25, and then the f25-based Atomic Host
image is updated. This provides something much more stable than basing
their releases on Rawhide, because only a fraction of the packages get
updated .
But we can't literally follow this model for workstation, because we
can't make that conceptual separation between the stable base and the
stuff that is updated - kernel, systemd, NetworkManager, gnome-shell
all have roughly the same status. The best separation we have for
Workstation is operating system vs. apps, and Flatpak is the route
forward to allow people to try out new apps on a stale base.
So what we converged on is to concentrate for now on making consuming
Rawhide via ostree better - once we get experience there, we can see
whether a *separate* rolling-but-stable stream might make sense and try
to convince the wider Fedora project about that.
I've listed some goals below, trying to order them from things that
are just a bit more than configuration changes, to things that require
a bit of implementation and development, to thing that are major
changes to how we work in Fedora.
Goal 1 (immediate)
==================
Have the ostree of at least the rawhide version of the ostree for
Fedora Workstation ("Fedora Atomic Workstation") rebuild more than once
a day. Right now fixing a problem with the ostree image is painful,
since either you have to set up a local build environment, or you can
test one change a day.
My understanding is that the way that this was resolved for Fedora
Atomic Host was that the compose for Fedora Atomic Host was separated
from the main compose, and the Atomic Host compose gets run in a cron
job every fifteen minutes or so (presumably throttling on the
completion of the last compose?)
Ways of proceeding:
* Have a separate "Fedora Atomic Workstation" compose copied from
however the Fedora Atomic Host compose is done.
* Run the entire Fedora Rawhide compose process out of a cron job,
like the Fedora Atomic Host compose. This would likely require us to
remove Rawhide from the mirrored set, but mirroring Rawhide doesn't
seem important - it is presumably a tiny portion of overall Fedora
bandwidth usage.
* Run just the *workstation* Fedora Rawhide compose out of a cron job
- I don't know how separable one edition is from the overall process.
Goal 2 (immediate)
================
Have a branch for the ostree repository for Fedora Workstation rawhide
that updates once a week rather than with every compose. This could be:
* Simply done at a fixed time
* Gated based on a human (possibly looking at the results of automated
tests)
* Gated automatically based on tests
We'd also want to make sure that there are install ISOs of these tags -
we possibly could only build ISOs when a tag is made to speed up the
continuous ostree compose process.
Goal 3 (short-term)
===================
Have tests that run automatically on the workstation ostree
repositories.
Goal 4 (short-term)
===================
Have some way to cherry pick selected security fixes and do an async-
update of the once-a-week tag. This would involve some sort of snap-
shot of the state of the koji tag used to build that version that could
then be cloned and updated with newer versions.
Goal 5 (longer-term)
====================
Extend the continuous build process to also apply to to bodhi-managed
distributions whether released (like f25) or unreleased (like f26).
ostree branches corresponding to updates and updates-testing would be
built continuously for testing purposes and automated tests would be
run against them.
Goal 6 (longer-term)
====================
Have a way of doing development branches (corresponding roughly to
side-tags in Koji) so that someone working on the next version of GNOME
or systemd can land changes and get them run through CI without
breaking people following rawhide.
Goal 7 (future)
===============
Have a "rolling stable" stream of Fedora that gets major updates not on
a six-month-tempo, but after those changes have seen testing in
Rawhide. We already treat the kernel like this.