= Proposed System Wide Change: DNF System Upgrades =
* Will Woods (fedup author)
* Zbigniew Jędrzejewski-Szmek (systemd developer)
* Radek Holy (DNF developer)
== Detailed Description ==
While fedup worked well in many circumstances, there were a lot of
problems resulting from using upgrade.img. This has caused nasty,
hard-to-debug blocker bugs for every release since it was introduced.
It turns out that upgrade.img was relying on some undocumented,
unsupported systemd behavior. After F22 this was discussed on the
systemd-devel mailing list, and the conclusion was that fedup's boot
behavior is broken by design, and systemd can't (and won't) continue to
systemd already supports a simpler, more reliable method for performing
Offline System Updates; the systemd team suggests using that to perform
Most of the remaining problems with fedup were caused by the fact that
it was separate from the system packaging tools, and therefore had
slight (and confusing) differences from the normal package update
Therefore, we propose that system upgrades should be handled by the
system packaging tools, using systemd's Offline System Updates facility.
dnf-plugin-fedup is a proof-of-concept implementation; we propose to
integrate support for this into DNF itself.
== Scope ==
Make DNF able to send progress output to Plymouth (basically done; see
dnf #281 and #313)
Modify Offline System Updates spec as needed to support major system
upgrades (in progress, see this systemd-devel thread)
Support Offline System Updates in DNF (dnf-plugin-fedup does this, but
it could be integrated into DNF itself)
Add plugin to dnf-plugins-core or dnf
Write man pages and other documentation
Obsolete and retire fedup
Fix any conflicts with packagekit-offline-update.service
In the unlikely event that some kind of offline system migration is
necessary (like UsrMove), it should be handled the same way as UsrMove
- i.e. by a dracut script that runs the first time the new system boots after the upgrade.
Drop upgrade.img from image builds
Policies and guidelines:
FedUp, Upgrading, and other documentation will need changes
the 3.17.4 release of evolution-data-server changes soname versions for
camel, libecal and libedata-cal, due to some API changes in respective
I will rebuild packages for which I have commit rights, the same as I
can help with the API change fixes, thus feel free to ping me or drop
Fedora 23 has been branched, please be sure to do a git pull --rebase to
pick up the new branch, as an additional reminder rawhide/f24 has had
inheritance cut off from previous releases, so this means that
anything you do for f23 you also have to do in the master branch and do
a build there. This is the same as we did for previous Fedora releases.
Fedora 23 Change Checkpoint: Completion deadline (testable) is in
two weeks - 2015-07-28  and we're getting closer to this date.
Other important milestones are scheduled for this date:
* Alpha Freeze
* Software String Freeze
* Bodhi activation point
At this point, all accepted changes should be substantially complete,
and testable. Additionally, if a change is to be enabled by default,
it must be so enabled at Change Completion deadline.
Change tracking bug should be set to the MODIFIED state to indicate
it achieved completeness.
Incomplete and non testable Changes will be reported to
FESCo for 2015-07-29 meeting. Contingency plan for System Wide Changes,
if planned for Alpha (or in case of serious doubts regarding Change
completion), will be activated.
Platform Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Layered Docker Image Build Service =
* Colin Walters <walters AT redhat DOT com>
* Adam Miller <maxamillion AT gmail DOT com >
* Tomas Tomecek <ttomecek AT redhat DOT com>
* Tim Waugh <twaugh AT redhat DOT com>
Fedora currently ships a Docker base image, but Docker supports a layering concept. There are some applications like Cockpit which we would like to ship as layered applications.
This change will deploy the build service to support building and delivering a set of layered Docker images, and will enable Fedora contributors to create and maintain Dockerfiles from which those images will be generated.
== Detailed Description ==
This change opens up an new type of official binary artifact produced by Fedora. Currently, we produce two main types of artifacts: RPMs, and images. The RPMs are created in Koji from specfiles in dist-git. The images come in different formats, but have in common creation in Koji from kickstart files — this includes the official Fedora Docker Base Image. This change introduces a new type of image, a Docker Layered Image, which is created from a Dockerfile and builds on top of that base image.
The system has five major parts:
* A command-line client — already integrated into rpkg; needs only minor work to enable in fedpkg
* dist-git for Dockerfiles
* A koji plugin, containerbuild
* An OpenShift 3 backend
* A distribution mechanism; initially, this will be
1. ftp/http mirror (either alt or main mirrors), and
2. pushed to upstream Docker hub (running our own registry is currently out of scope; see below)
For more information, see this presentation for the high level overview of the whole system.
== Scope ==
For the Scope of this Change please check https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service...