https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Make DNF5 the new default packaging tool. The change will replace DNF,
LIBDNF, and DNF-AUTOMATIC with the new DNF5 and new Libdnf5 library.
It is a second step after
https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf.
== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek(a)redhat.com
== Detailed Description ==
The new DNF5 will provide a significant improvement in user
experiences and performance. The replacement is the second step in
upgrade of Fedora Software Management stack. Without the change there
will be multiple software management tool (DNF5, old Microdnf,
PackageKit, and DNF) based on different libraries (libdnf, libdnf5),
providing a different behavior, and not sharing a history. We can also
expect that DNF will have only limited support from upstream. The DNF5
development was announced on
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Fedora-Devel] list in 2020.
=== New DNF5 Features ===
* Fully featured package manager without requirement of Python
** Smaller system
** Faster
** Replace DNF and Microdnf
* Unified behavior of in the software management stack
** New Libdnf5 plugins (C++, Python) will be applicable to DNF5, Dnf5Daemon
*** DNF4 plugins were not applicable for PackageKit and Microdnf (e.g.
versionlock, subscription-manager), therefore PackageKit behaves
differently in comparison to DNF
** Shared configurations
*** In DNF4 not all configuration is honored by PackageKit and Microdnf
** DNF/YUM was developed for decades with impact of multiple styles
and naming conventions (options, configuration, options, commands)
* New Daemon
** The new daemon can provide an alternative to PackageKit for RPMs
(only one backend of PackageKit) if it will be integrated into Desktop
** Support of Modularity and Comps group
* Performance improvement
** Loading of repositories
** Advisory operations
** RPM queries
*** Name filters with a case-insensitive search (the `repoquery` command)
** Smart sharing of metadata between dnf5 and daemon
*** Reduce disk and downloads requirements
*** Currently, DNF, Microdnf, and PackageKit use their own cache
*** Optional, may be not available for Fedora 39
* Decrease of a maintenance cost in the long term
** Shared plugins
** Removal of functional duplicates
* Fully integrated Modularity in LIBDNF5 workflows
** The Modularity is supported in DNF and LIBDNF but it is not fully
integrated. Integration was not possible due to limitation of
compatibility with other tools (PackageKit)
** Fully integrated Modularity required changes in the library workflow
=== Major codebase improvements ===
*Reports in structure
** DNF reports a lot of important information only in logs
* Removal of duplicated implementation
** LIBDNF evolved from LIBHIF (PackageKit library) and HAWKEY (DNF
library). The integration was never finished, therefore LIBDNF still
contains duplicated functionality.
** decrease of the code maintenance cost in future
* Unify Python bindings
** Formal Libdnf provides two types of Python bindings
*** CPython (hawkey)
*** SWIG (libdnf)
** Maintaining and communication between both bindings requires a lot
of resources
** Binding unification was not possible without breaking API compatibility
* SWIG bindings
** With SWIG we can generate additional bindings without spending huge resources
** Code in particular languages will be very similar to each other
* Separation of system state from history DB and `/etc/dnf/module.d`
** In dnf-4 the list of userinstalled packages and list of installed
groups along with the lists of packages installed from them is
computed as an aggregation of transaction history. In dnf5 it will be
stored separately, having multiple benefits, among them that the
history database will serve for informational purposes only and will
not define the state of the system (it gets corrupted occasionally
etc.).
** Data stored in `/etc/dnf/module.d` were not supposed to be user
modifiable and their format is not sufficient (missing information
about installed packages with installed profiles)
*** Content of `/etc/dnf/module.d` will be moved into the System State
== Feedback ==
== Benefit to Fedora ==
== Scope ==
* Proposal owners:
DNF5 is still in the development and some of the features or options
are not yet available. We still have to finish the implementation of
Modularity, storing internal data related to History and System State,
and also documentation and man pages. DNF5 can be tested from
repository with upstream nightly builds -
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/.
The project's github repository is here -
https://github.com/rpm-software-management/dnf5/
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`,
and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`,
`python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`.
=== Compatibility ===
The new DNF5 will provide a symlink to `/usr/bin/dnf` therefore users
will see the replacement as an upgrade of DNF with limited but
documented syntax changes. The DNF5 will provide some compatible
aliases of commands and options to improve adoption of the DNF5.
== How To Test ==
Install `dnf5` package from
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/
== User Experience ==
* Improved progress bars
* Improved transaction table
* Transaction progress reports including scriptlets reports
* Support of local rpm for transaction operation
* Great bash completion (better then DNF has)
* New commands and options that are only available with `DNF`
== Dependencies ==
There is a long list of dependent packages
=== dnf ===
auter
calamares
copr-builder
cpanspec
dnf-plugin-diff
dnfdragora
etckeeper-dnf
fedora-review
fedora-upgrade
kiwi-systemdeps-core
libdnf-plugin-subscription-manager
lpf
mock
osbuild
perl-CPAN-Plugin-Sysdeps
policycoreutils-devel
rbm
subscription-manager
supermin
system-config-language
=== python3-dnf ===
anaconda-core
dnf-plugin-ovl
dnfdaemon
fedora-easy-karma
fedora-review
lorax
mock-core-configs
module-build-service
modulemd-tools
needrestart
pungi
python3-bodhi-client
python3-dnf-plugin-cow
python3-dnf-plugin-flunk_dependent_remove
python3-imgcreate
python3-libreport
retrace-server
system-config-language
=== libdnf ===
PackageKit
copr-builder
gnome-software-rpm-ostree
libdnf-plugin-subscription-manager
libdnf-plugin-swidtags
libdnf-plugin-txnupd
=== python3-hawkey ===
mock-core-configs
modulemd-tools
python3-rpmdeplint
retrace-server
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
* Contingency deadline:
* Blocks release?
== Documentation ==
none
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Do you want to make Fedora 37 better? Please spend 1 minute of your time and try to run:
# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'
dnf --releasever=37 --setopt=module_platform_id=platform:f37 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) \
--assumeno distro-sync
This command does not replace `dnf system-upgrade`, but it will reveal potential problems.
You may also run `dnf upgrade` before running this command.
The `--assumeno` will just test the transaction, but does not make the actual upgrade.
In case you hit dependency issues, please report it against the appropriate package.
Or against fedora-obsolete-packages if that package should be removed in Fedora 37. Please check existing reports against
fedora-obsolete-packages first:
https://red.ht/2kuBDPu
and also there is already bunch of "Fails to install" (F37FailsToInstall) reports:
https://bugzilla.redhat.com/buglist.cgi?bug_id=2045109&bug_id_type=anddepen…
Thank you
Miroslav
Summary----------
Most all Fedora variants (except Cloud) have a GRUB menu entry
containing the word "rescue". This kernel+initramfs pair are never
updated for the life of a Fedora installation. And they quickly become
stale as a Fedora installation ages. This kernel's modules are
eventually deleted, and if selected at boot time, the typical user
experience is a dracut shell.
Basic background-------------
(skip this section if you know how it works)
During a new installation, a single kernel version is installed. e.g.
vmlinuz-5.17.0-0.rc4.96.fc36.x86_64 which is then duplicated as e.g.
vmlinuz-0-rescue-3a86878de5d649a983916543ece7bb7e.
Each of those (identical) kernels has an initramfs file:
initramfs-5.17.0-0.rc4.96.fc36.x86_64.img
initramfs-0-rescue-3a86878de5d649a983916543ece7bb7e.img
The sole difference is the first one is a smaller host-only initramfs,
the second one is a larger no host-only initramfs created with `dracut
-N`. The bigger one just contains a bunch of extra kernel modules and
dracut scripts, ostensibly to make it more likely to boot a system
with some change in hardware that the host-only initramfs doesn't
contain. The size of this rescue initramfs is around 100 MiB, with the
common day to day "host only" initramfs being around 33 MiB. [1]
As the system is updated, additional kernel versions are installed.
dnf.conf contains installonly_limit=3, which results in a maximum of
three kernel versions being installed at a time. Once a fourth kernel
is installed, the first kernel and its modules are removed from
/usr/lib/modules. The rescue kernel+initramfs pair are never updated
or upgraded, even during system upgrades.
Observations------------
This has been discussed by the Workstation working group [2] but since
this functionality is present in all of Fedora, we're moving the
discussion for greater visibility.
There's two separate complaints, if you will: (a) that the
kernel+initramfs pair are never update or upgraded for the life of the
installation; and (b) that even during one release cycle, the user
experience when booting the rescue entry, changes, i.e. when the
matching /usr/lib/modules for the rescue entry are present early on,
you do get a full runtime behavior, you will get to a graphical
environment. But then once the version matched /usr/lib/modules are
removed, you get a completely different behavior when booting the
rescue entry.
An important note from that ticket from Justin Forbes, the Fedora
kernel maintainer: " Remember, the only real purpose of the rescue
kernel is to get your system out of something completely unusable. It
isn't meant to be a full runtime."
Questions------------
* Considering the very narrow purpose of the entry, maybe the current
behavior is adequate?
* Does the rescue entry reliably get users to a dracut prompt, rather
than indefinite hang? I don't know whether it does.
* Is there any way to improve the situation without increasing the
risk that the rescue entry becomes totally non-functional?
* The chosen kernel version needs to be based on one that is known
to boot. Currently we know the kernel+initramfs pair work because it's
the same version used to boot the installation media when doing the
initial provisioning. We don't actually know an updated replacement
"no host-only" initramfs will work until it's tried. Is it possible to
automate this? And is it worth the risk, or even figuring out how to
assess the risk?
* At Flock 2021, Zbyszek proposed "Building Initrd Images from
RPMs" to reduce the complexity of building initramfs, maybe there's a
role for it here? More: https://www.youtube.com/watch?v=GATg_bqmASc
* What happens if we accept some scope creep, and go for many
improvements that make the extra work worth it?
* What about the unsigned nature of the initramfs? Should we be
creating initramfs's in Fedora infra and signing them?
* Stuff a graphical rescue environment into the initramfs? (This
might be ten leaps too far, but it's intended to encourage thinking
with a vivid imagination.)
[1] both values from a recent Fedora 36 Workstation installation
[2] https://pagure.io/fedora-workstation/issue/259
--
Chris Murphy
The following packages, previously owned by xgl-maint, are now up for grabs:
xorg-x11-xfs
xorg-sgml-doctools
xorg-x11-drv-v4l
xorg-x11-xsm
xorg-x11-twm
xorg-x11-drv-sisusb
xorg-x11-xdm
xorg-x11-docs
Upstream development on all of these is pretty much nil, so if you're
serious about picking up any of these you may also wish to take on the
module upstream:
https://gitlab.freedesktop.org/xorg
- ajax
https://fedoraproject.org/wiki/Changes/RpmSequoia
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Change RPM to use [https://sequoia-pgp.org/ Sequoia] based OpenPGP
parser instead of it's own, flawed and limited implementation.
== Owner ==
* Name: [[User:pmatilai| Panu Matilainen]]
* Email: pmatilai(a)redhat.com
== Detailed Description ==
For the last 20 years or so, RPM has used a home-grown OpenPGP parser
for dealing with keys and signatures. That parser is rather infamous
for its limitations and flaws, and especially in recent years has
proven a significant burden to RPM development. In order to improve
security and free developer resources for dealing with RPM's "core
business" instead, RPM upstream is in the process of deprecating the
internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
based solution written in Rust.
At this point the change is mostly invisible in normal daily use.
== Feedback ==
== Benefit to Fedora ==
The main, direct benefit to Fedora is improved security and
standards-compliance (RFC-4880) in one of the corner-stones of the
whole distribution. Longer term, we can expect better error messages
and other functional improvements regarding key and signature
handling.
== Scope ==
* Proposal owners:
** Help [https://bugzilla.redhat.com/show_bug.cgi?id=2087499
package/review rpm-sequoia]
** Build rpm with --with-crypto=sequoia
** Watch out for the unexpected
* Other developers:
** Help [https://bugzilla.redhat.com/show_bug.cgi?id=2087499
package/review rpm-sequoia]
* Release engineering: [https://pagure.io/releng/issue/11077 #11077]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Within Fedora package set, this has no impact as everything is already
using sufficiently strong crypto. Third party repositories / packages
could be signed with insecure crypto, and those may require working
around with --nosignature. However this incidentally overlaps with
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2
which has effectively the same effect on rpm.
== How To Test ==
In general, normal rpm/dnf use provides sufficient test coverage. For
more advanced testers: try signing and verifying with different keys
and their subkeys, using different algorithms etc.
== User Experience ==
For normal usage, the change is quite invisible. The notable exceptions are
- Some old, insecure (MD5/SHA1 based) signatures are rejected (this is
in line with the stronger crypto settings proposed elsewhere for F38)
- Key import may accept some previously rejected keys, in part due to
limitations of old parser etc but in particular, the old
implementation verifies self-signatures at import time whereas Sequoia
verifies them at time of use.
- Key import may reject some previously accepted keys due to better validation.
== Dependencies ==
The change introduces one new direct dependency:
[https://github.com/rpm-software-management/rpm-sequoia/ rpm-sequoia].
The rpm-sequoia package also takes over other crypto besides OpenPGP,
currently Sequoia uses nettle as its low-level crypto provider, but
work is underway to
[https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1361 support
openssl in Sequoia], and the plan is to have Sequoia in Fedora use
that once it becomes available. This plan
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
has support of the crypto team].
== Contingency Plan ==
* Contingency mechanism: Revert back to the internal PGP parser
* Contingency deadline: Beta release
* Blocks release? No
== Documentation ==
There's not much in the way of documentation as there's not much to
document, except for the deprecation of the internal parser:
https://github.com/rpm-software-management/rpm/issues/1935
rpm-sequoia build instructions can be found in
https://github.com/rpm-software-management/rpm-sequoia/
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/NodejsRepackaging
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
We are reworking the Node.js packaging to make Node.js versions
available as parallel-installable packages.
== Owner ==
* Name: [[User:SGallagh| Stephen Gallagher]]
* Email: sgallagh(a)redhat.com
== Detailed Description ==
We will be creating the packages nodejs-16, nodejs-18 and (in April)
nodejs-20. These packages will be parallel-installable (with the
exception of the -devel subpackages) and provide
`/usr/bin/node-$MAJOR`. We will also take advantage of the
`alternatives` subsystem to populate `/usr/bin/node` from the default
Node.js version for that release, or if the default is not installed,
the highest currently-installed version.
Notes:
* The default in Fedora 38 will be Node.js 18. If a user was to
install Node.js 16 and Node.js 20, but not Node.js 18, then Node.js 20
would provide `/usr/bin/node`
* The policy going forward will be to have the most recently-released
version of Node.js at the time of Fedora's expected Beta release date
be the default for that release throughout its lifetime.
== Feedback ==
[https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject.or…
Mailing list thread]
Neal Gompa raised the question of using a subpackage to own
`/usr/bin/node` instead of using the `alternatives` subsystem, citing
python as an example. My response was that the problem with this is
that I want `/usr/bin/node` to always be available so long as any
`nodejs-$MAJOR` version is installed. It also ensures that the
`node(1)` manpage always matches the `/usr/bin/node` executable.
== Benefit to Fedora ==
=== User Benefits ===
* Provides a simple way to have a different (or multiple) Node.js
interpreters on their system. No dealing with Modularity.
* Enables multiple versions of Node.js on the system (can test code
against different versions without using containers)
=== Packager Benefits ===
* No more modules to maintain.
* Availability of multiple Node.js versions in the buildroot means
that other `nodejs-*` packages can test against multiple supported
options.
== Scope ==
* Proposal owners:
The packaging work is done and can be played with at
https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/
today.
* Other developers:
There should be no need to change any dependent packages, though
packagers of Node.js software may wish to take advantage of the
testing opportunities afforded.
* Release engineering:
* Policies and guidelines: We will be updating the Node.js Packaging
Guidelines with the new best practices.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Systems using the existing nodejs RPM package will be upgraded to the
matching `nodejs-$MAJOR` version. Work is pending on how to migrate
users of Modular Node.js to the new packages.
== How To Test ==
== User Experience ==
Done correctly, this should be handled entirely without the user's
need to know about it.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject.or…
== Release Notes ==
Multiple releases of Node.js may now be installed in parallel from the
Fedora repositories.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Continue the work done in
https://fedoraproject.org/wiki/Changes/OstreeNativeContainer but in an
officially stable format, and expanded to cover more OSTree-based
editions. This goes "all in" on being container-native and
significantly changes the technology and user emphasis.
== Owner ==
* Name: [[User:walters| Colin Walters]], [[User:jmarrero| Joseph
Marrero]], [[User:baude| Brent Baude]]
* Email: walters(a)verbum.org, jmarrero(a)fedoraproject.org, baude(a)fedoraproject.org
== Detailed Description ==
* rpm-ostree's functionality to
[https://coreos.github.io/rpm-ostree/container/ boot and upgrade from
Docker/OCI container images] is declared stable
* Rework Fedora editions and spins (CoreOS, IoT, Silverblue, Kinoite,
etc) that use ostree to instead deliver via Docker/OCI container
images
* `rpm-ostree` is reworked to gain strong CLI compatibility with
`yum/dnf` commands (cliwrap)
* The new container native functionality is exposed via `dnf image`
* (TBD: Rebranding of rpm-ostree itself to `dnf-image` or something else)
* Support and documentation for generating derived images
* Support in Anaconda and other tools
* Support for generating bootable images
A top level goal is that users should not need to know or understand
ostree (or rpm-ostree); they only need to know containers and most key
functionality is exposed via the `yum/dnf` frontend with a few
extensions.
=== Backwards compatibility ===
If you're a user of ostree today: no need to worry. Everything that
works today in ostree and rpm-ostree will continue to work for years
to come (it's shipped in RHEL9). However, it's expected that most
users will find the new model sufficiently compelling to switch fairly
quickly.
=== Stable Bootable OCI ===
More information about this is available in
[https://coreos.github.io/rpm-ostree/container/ the rpm-ostree
documentation]. This Change highlights that this functionality is
planned to be officially stable.
=== Changing to OCI over the wire ===
Today Fedora has an OSTree repository that contains updates for
editions such as Fedora CoreOS and Fedora Silverblue.
These editions instead will become [https://github.com/opencontainers
OCI base images], available at e.g.
* `quay.io/fedora/fedora-coreos:stable`
([https://quay.io/repository/fedora/fedora-coreos this exists today]!)
* `quay.io/fedora/fedora-silverblue:38` (does not exist, but can soon)
An update will be shipped that will cause existing systems tracking
the production ostree branches to be switched to the corresponding
container image. Concretely for example, a system running
`fedora:fedora/36/x86_64/silverblue` will execute `rpm-ostree rebase
ostree-remote-registry:fedora:quay.io/fedora/fedora-silverblue:36`.
Note that at the current time, Fedora does not sign container images.
This should change (likely to something based on
[cosign](https://github.com/containers/skopeo/pull/1701)) but in the
mean time, the ostree-container flow supports verifying the embedded
ostree-baesd GPG signatures and this will continue to be used.
The Fedora OSTree repository will become read-only and stop receiving updates.
Note that for Fedora CoreOS specifically, there is some outstanding
design discussion around the intersection with Cincinnati:
https://github.com/coreos/fedora-coreos-tracker/issues/1263
==== Wire efficiency ====
Today the container images generated by rpm-ostree are "chunked" in a
reproducible fashion; for more information on this, see
* https://github.com/ostreedev/ostree-rs-ext/issues/69
* https://coreos.github.io/rpm-ostree/container/
However, longer term (as that first issue notes) we do want to add
[https://github.com/containers/image/pull/902 container deltas].
Doing so will benefit non-host containers too.
=== dnf/yum CLI compatibility ===
rpm-ostree has a feature called
[cliwrap](https://coreos.github.io/rpm-ostree/cliwrap/) today. A key
motivation here is that in the switch to using containers as the
frontend, the project name "rpm-ostree" (which is very literal) no
longer makes sense. A further emphasis on "container native" will
strongly encourage writing e.g. a `Dockerfile` like this:
<pre>
FROM quay.io/fedora/fedora-silverblue:stable
RUN dnf -y install sway && ostree container commit
</pre>
*Today*, one can spell this as `RUN rpm-ostree install -y sway &&
ostree container commit` - but a toplevel goal here is to allow host
system customization using the same patterns and tools one uses to
build application containers, and to de-emphasize the "ostree backend"
aspect.
To complete this story on the client side, what is today called
"ostree native containers" will be exposed via a new `dnf image`
subcommand on the client system.
For example:
<pre>
$ dnf image rebase quay.io/examplecorp/customos:latest
</pre>
As well as other offline/"image based" functionality such as `dnf
image rollback` and `dnf image apply-live`.
However, as many people know, rpm-ostree does today support
"per-machine" package layering/overrides - and *that will continue to
work*. So users are not *required* to do builds on a remote server
even in "image mode".
Concretely, it will also work to `sudo dnf -y install sway` inside a
root terminal on a Fedora Workstation for example. This will still be
a transactional operation.
More: https://github.com/coreos/rpm-ostree/issues/2883
=== Rebranding of rpm-ostree ===
This is a fundamental change in technology *and* positioning for
rpm-ostree (and for the projects that use it). The terminology of
"immutable" gets even fuzzier now (see also [this
blog](https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionabl…)
It would make sense to rebrand the project due to this. No decision
has been made on this, but the choices are:
- Keep as is
- Rebrand to dnf-image (or, reviving a past name, yum-image)
- Rebrand to something else
More: https://github.com/coreos/rpm-ostree/issues/405
=== Support for building derivative containers ===
Until now, the model for systems like Fedora CoreOS and Silverblue
etc. has included an emphasis on containerization, but avoiding
extensive customization of the host system. This will be weakened
somewhat - it will be fully supported to build derivative operating
system images that in turn contain software which itself should run
directly on the host system, and not in a container.
A key aspect of this is that by generating a custom build, one binds
together the code and configuration as a transactionally updatable
unit.
The role of things like Kickstart, cloud-init, and Ignition and other
system config management shrinks significantly.
=== Example 1: Kubernetes and kubelet ===
It is not supported upstream to run the kubelet in a container image
itself. Today, for OpenShift 4 we embed the kubelet as part of the
CoreOS builds. The [https://www.okd.io/ OKD] project
[https://github.com/openshift/okd-machine-os/blob/fa2248d332abc9926e68428dc6…
already installs kubelet during a container build] deriving from the
base `fedora-coreos` image. It is possible that RHEL CoreOS will make
[https://github.com/openshift/os/issues/799 a similar split].
=== Example 2: Agent software ===
Many organizations require agents (cloud agents, security scanners,
antivirus) which are not ready to be containerized. Often too, these
tools come in e.g. RPM form, and also expect to be configured (remote
logging server, etc.). This tooling allows to `dnf install` these
*and* embed the configuration, generating a standard container image
which can then be booted as an atomic unit.
(Note that in the OpenShift context, we expect this to chain with the
first example - users instead derive from a `okd-node-base` image
which itself derives from `fedora-coreos`).
=== Example 3: Podman machine ===
The `[http://podman.io Podman]` project has a function called
`[https://github.com/containers/podman/blob/main/docs/source/markdown/podman-machine.1.md
machine]` where it creates a virtual machine and boots standard CoreOS
builds. Podman developers and users has long desired a custom FCOS
image that is focused on container deployment using Podman, including
certain QEMU packages that allow for cross-architecture development.
This approach will solve a series of problems including but not
limited to getting more timely release alignment between Podman and
FCOS.
We also have a user base that wants to customize the VM image based on
restrictive environments ... bring your own virtual machine image.
=== Support in Anaconda and other tools ===
Anaconda support for custom images is tracked in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2125655
But, as part of this Change, it should also work to generate an
Anaconda ISO which allows *user choice* for whether to install in
"image mode" or "traditional".
=== Support for generating bootable images ===
Instead of using an existing disk image/ISO (Anaconda, AWS AMI, etc.)
and then doing an in-place update to a generated container image, in
many cases will want to generate disk images using their container
image as input.
For example, generating an ISO that embeds that container image as
input and will install it.
In this proposal, we plan to ship a container image as part of Fedora
CoreOS that will do this:
https://github.com/coreos/fedora-coreos-tracker/issues/1151
But, it also makes sense to have a tool that e.g. does this and
generates an Anaconda ISO (we will inherently be doing this as part of
generating ostree-based Anaconda ISOs already!) - this would just be
supporting that in a clear external way too. One likely target for
this is [https://github.com/osbuild osbuild] and
[https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/ht…
RHEL Image Builder].
== Feedback ==
== Benefit to Fedora ==
The need to understand ostree goes away for most users; they
understand RPMs and containers. While retaining all the current
(rpm-)ostree features.
== Scope ==
* Proposal owners:
* Other developers: May affect e.g. gnome-software and similar tools
that talk to rpm-ostree.
* Release engineering: [https://pagure.io/releng/issue/11047]
* Policies and guidelines: None.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: None
== Upgrade/compatibility impact ==
We will ship a systemd unit that transitions systems currently using
OSTree on the wire over to tracking the corresponding container
images. Note again, all features of rpm-ostree continue to work! For
example, if you have layered packages, that will continue to be
applied.
== How To Test ==
Build container images, boot them.
== User Experience ==
Users will not need to understand ostree (at least at a superficial
level), only container images.
== Dependencies ==
Needs improvements in Anaconda in some cases, also would like to
increase alignment with dnf. Fetching container images uses `skopeo`,
maintained by containers team.
== Contingency Plan ==
* Contingency mechanism: Continue to ship things the way we ship them today
* Contingency deadline: Dunno
* Blocks release? No
== Documentation ==
https://coreos.github.io/rpm-ostree/container/ and
https://github.com/coreos/coreos-layering-examples etc.
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Fedora will add -fno-omit-frame-pointer to the default C/C++
compilation flags, which will improve the effectiveness of profiling
and debugging tools.
== Owner ==
* Name: [[User:daandemeyer| Daan De Meyer]], [[User:Dcavalca| Davide
Cavalca]], [[ Andrii Nakryiko]]
* Email: daandemeyer(a)fb.com, dcavalca(a)fb.com, andriin(a)fb.com
== Detailed Description ==
Credits to Mirek Klimos, whose internal note on stacktrace unwinding
formed the basis for this change proposal (myreggg(a)gmail.com)
Any performance or efficiency work relies on accurate profiling data.
Sampling profilers probe the target program's call stack at regular
intervals and store the stack traces. If we collect enough of them, we
can closely approximate the real cost of a library or function with
minimal runtime overhead.
Stack trace capture what’s running on a thread. It should start with
clone - if the thread was created via clone syscall - or with _start -
if it’s the main thread of the process. The last function in the stack
trace is code that CPU is currently executing. If a stack starts with
[unknown] or any other symbol, it means it's not complete.
=== Unwinding ===
How does the profiler get the list of function names? There are two parts of it:
# Unwinding the stack - getting a list of virtual addresses pointing
to the executable code
# Symbolization - translating virtual addresses into human-readable
information, like function name, inlined functions at the address, or
file name and line number.
Unwinding is what we're interested in for the purpose of this
proposal. The important things are:
* Data on stack is split into frames, each frame belonging to one function.
* Right before each function call, the return address is put on the
stack. This is the instruction address in the caller to which we will
eventually return — and that's what we care about.
* One register, called the "frame pointer" or "base pointer" register
(RBP), is traditionally used to point to the beginning of the current
frame. Every function should back up RBP onto the stack and set it
properly at the very beginning.
The “frame pointer” part is achieved by adding push %rbp, mov
%rsp,%rbp to the beginning of every function and by adding pop %rbp
before returning. Using this knowledge, stack unwinding boils down to
traversing a linked list:
https://i.imgur.com/P6pFdPD.png
=== Where’s the catch? ===
The frame pointer register is not necessary to run a compiled binary.
It makes it easy to unwind the stack, and some debugging tools rely on
frame pointers, but the compiler knows how much data it put on the
stack, so it can generate code that doesn't need the RBP. Not using
the frame pointer register can make a program more efficient:
* We don’t need to back up the value of the register onto the stack,
which saves 3 instructions per function.
* We can treat the RBP as a general-purpose register and use it for
something else.
Whether the compiler sets frame pointer or not is controlled by the
-fomit-frame-pointer flag and the default is "omit", meaning we can’t
use this method of stack unwinding by default.
To make it possible to rely on the frame pointer being available,
we'll add -fno-omit-frame-pointer to the default C/C++ compilation
flags. This will instruct the compiler to make sure the frame pointer
is always available. This will in turn allow profiling tools to
provide accurate performance data which can drive performance
improvements in core libraries and executables.
== Feedback ==
=== Potential performance impact ===
* Meta builds all its libraries and executables with
-fno-omit-frame-pointer by default. Internal benchmarks did not show
significant impact on performance when omitting the frame pointer for
two of our most performance intensive applications.
* Firefox recently landed a change to preserve the frame pointer in
all jitted code
(https://bugzilla.mozilla.org/show_bug.cgi?id=1426134) No significant
decrease in performance was observed.
* Kernel 4.8 frame pointer benchmarks by Suse showed 5%-10%
regressions in some benchmarks
(https://lore.kernel.org/all/20170602104048.jkkzssljsompjdwy@suse.de/T/#u)
Should individual libraries or executables notice a significant
performance degradation caused by including the frame pointer
everywhere, these packages can opt-out on an individual basis as
described in https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags.
=== Alternatives to frame pointers ===
There are a few alternative ways to unwind stacks instead of using the
frame pointer:
* [https://dwarfstd.org DWARF] data - The compiler can emit extra
information that allows us to find the beginning of the frame without
the frame pointer, which means we can walk the stack exactly as
before. The problem is that we need to unwind the stack in kernel
space which isn't implemented in the kernel. Given that the kernel
implemented it's own format (ORC) instead of using DWARF, it's
unlikely that we'll see a DWARF unwinder in the kernel any time soon.
The perf tool allows you to use the DWARF data with
--call-graph=dwarf, but this means that it copies the full stack on
every event and unwinds in user space. This has very high overhead.
* [https://www.kernel.org/doc/html/v5.3/x86/orc-unwinder.html ORC]
(undwarf) - problems with unwinding in kernel led to creation of
another format with the same purpose as DWARF, just much simpler. This
can only be used to unwind kernel stack traces; it doesn't help us
with userspace stacks. More information on ORC can be found
[https://lwn.net/Articles/728339 here].
* [https://lwn.net/Articles/680985 LBR] - New Intel CPUs have a
feature that gives you source and target addresses for the last 16 (or
32, in newer CPUs) branches with no overhead. It can be configured to
record only function calls and to be used as a stack, which means it
can be used to get the stack trace. Sadly, you only get the last X
calls, and not the full stack trace, so the data can be very
incomplete. On top of that, many Fedora users might still be using
CPUs without LBR support which means we wouldn't be able to assume
working profilers on a Fedora system by default.
To summarize, if we want complete stacks with reasonably low overhead
(which we do, there's no other way to get accurate profiling data from
running services), frame pointers are currently the best option.
== Benefit to Fedora ==
Implementing this change will provide profiling tools with easy access
to stacktraces of installed libraries and executables which will lead
to more accurate profiling data in general. This in turn can be used
to implement optimizations to core libraries and executables which
will improve the overall performance of Fedora itself and the wider
Linux ecosystem.
Various debugging tools can also make use of the frame pointer to
access the current stacktrace, although tools like gdb can already do
this to some degree via embedded dwarf debugging info.
== Scope ==
* Proposal owners: Put up a PR to change the rpm macros to build
packages by default with -fno-omit-frame-pointer by default.
* Other developers: Review and merge the PR implementing the Change.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number]. A mass rebuild is required.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
This should not impact upgrades in any way.
== How To Test ==
# Build the package with the updated rpm macros
# Profile the binary with `perf record -g <binary>`
# Inspect the perf data with `perf report -g 'graph,0.5,caller'`
# When expanding hot functions in the perf report, perf should show
the full call graph of the hot function (at least for all functions
that are part of the binary compiled with -fno-omit-frame-pointer)
== User Experience ==
Fedora users will be more likely to have a streamlined experience when
trying to debug/profile system executables/libraries. Tools such as
perf will work out of the box instead of requiring to users to provide
extra options (e.g. --call-graph=dwarf/LBR) or requiring users to
recompile all relevant packages with -fno-omit-frame-pointer.
== Dependencies ==
The rpm macros for Fedora need to be adjusted to include
-fno-omit-frame-pointer in the default C/C++ compilation flags.
== Contingency Plan ==
* Contingency mechanism: The new version can be released without every
package being rebuilt with fno-omit-frame-pointer. Profiling will only
work perfectly once all packages have been rebuilt but there will be
no regression in behavior if not all packages have been rebuilt by the
time of the release. If the Change is found to introduce unacceptable
regressions, the PR implementing it can be reverted and affected
packages can be rebuilt.
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
* Original proposal for in-kernel DWARF unwinder (rejected):
https://lkml.org/lkml/2017/5/5/571
== Release Notes ==
Packages are now compiled with frame pointers included by default.
This will enable a variety of profiling and debugging tools to show
more information out of the box.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis