F39 Change Proposal: Automatic Cloud Reboot on Updates
(Self-Contained Change)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/Automatic_Cloud_Reboot_On_Updates
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 ==
Cloud users can provide cloud-init metadata when creating a Fedora
cloud instance and that metadata can contain instructions to update
all packages on the system and reboot the system if any of those
updated packages need a reboot to go into effect. Fedora cloud
instances should write the `/var/run/reboot-required` file if a reboot
is needed after a dnf update so that cloud-init can reboot the
instance.
This issue originally surfaced in
[https://bugzilla.redhat.com/show_bug.cgi?id=1275409 RHBZ 1275409].
== Owner ==
* Name: [[User:mhayden| Major Hayden]]
* Email: major(a)redhat.com
== Detailed Description ==
Fedora cloud instances use cloud-init to do the initial configuration
of the instance. This includes setting up networking, assigning a
hostname, adding users/groups, and arbitrary scripts. There are also
two options that you can pass to cloud-init that are important for
this change:
* `package_update`: If set to `true`, all installed packages are
immediately updated on first boot
* `package_reboot_if_required`: If set to `true`, and the
`package_update` step wrote to `/var/run/reboot-required`, reboot the
system immediately after updating packages
📚 For more details, see cloud-init's module reference for
`[https://cloudinit.readthedocs.io/en/latest/reference/modules.html#package-update-upgrade-install
package_update]`.
🚨 '''WAIT A MOMENT. ARE WE TALKING ABOUT REBOOTING EVERY CLOUD
INSTANCE ON BOOT?''' 🚨 No! This change would require all three of
these things to happen before a reboot occurs:
* User provides `package_update: true` on instance creation
* '''AND''' user provides `package_reboot_if_required: true` on
instance creation
* '''AND''' `tracer` notices that at least one of the packages need a
reboot to go into effect
🤔 '''Where does this `/var/run/reboot-required` file come from?''' On
Debian and Ubuntu systems, `apt` automatically writes to
`/var/run/reboot-required` if a reboot is needed after a package
update. From there, `cloud-init` looks for the file
([https://github.com/canonical/cloud-init/blob/6d09df5e4786a2a6c79d6098ab41...
relevant cloud-init code]) and if present, reboots the system
immediately.
✏️ '''How do we write this file on Fedora?''' Fedora systems have a
package called `tracer` and a corresponding dnf plugin,
`python3-dnf-plugin-tracer`, that analyzes `dnf` updates and provides
recommendations on reboots or user logouts to bring updates into
effect on the system. A recent
[https://github.com/FrostyX/tracer/pull/196 pull request] added
support for writing the `/var/run/reboot-required` file when a system
reboot is recommended. The `cloud-init` tool can read this file after
a package update and reboot if needed.
🔎 '''What does `tracer`'s output look like?'''
[root@tracer-testing ~]# tracer
You should restart:
* Some applications using:
sudo systemctl restart NetworkManager
sudo systemctl restart auditd
sudo systemctl restart chronyd
sudo systemctl restart dbus-broker
sudo systemctl restart qemu-guest-agent
sudo systemctl restart sshd
sudo systemctl restart systemd-journald
sudo systemctl restart systemd-logind
sudo systemctl restart systemd-oomd
sudo systemctl restart systemd-resolved
sudo systemctl restart systemd-udevd
sudo systemctl restart systemd-userdbd
* These applications manually:
(sd-pam)
Additionally, there are:
- 3 processes requiring restart of your session (i.e. Logging out
& Logging in again)
- 1 processes requiring reboot
[root@tracer-testing ~]# cat /var/run/reboot-required
Tracer says reboot is required
📋 '''What do we need to do?''' Add the `python3-dnf-plugin-tracer`
plugin to Fedora cloud images. No additional configuration is
necessary. This action pulls in five packages that are about 2.1MB
after installation:
=======================================================================================
Package Arch Version
Repository Size
=======================================================================================
Installing:
python3-dnf-plugin-tracer noarch 4.1.0-1.fc38
fedora 14 k
Installing dependencies:
python3-dnf-plugins-extras-common noarch 4.1.0-1.fc38
fedora 69 k
python3-psutil x86_64 5.9.2-2.fc38
fedora 271 k
python3-tracer noarch 0.7.8-5.fc38
fedora 172 k
tracer-common noarch 0.7.8-5.fc38
fedora 22 k
Transaction Summary
=======================================================================================
Install 5 Packages
Total download size: 547 k
Installed size: 2.1 M
== Feedback ==
One of the other ideas was to patch `cloud-init` to run `tracer`
directly and avoid the `/var/run/reboot-required` file altogether.
That would require a lot of work upstream in `cloud-init` to enable
the functionality and we would still need the same set of packages
installed in Fedora anyway. 🥵
== Benefit to Fedora ==
This change allows Fedora cloud instances to behave in the same way
that Debian-based instances already behave. When users request package
updates with a reboot now, `cloud-init` performs the update but never
reboots the system. This is an unexpected and confusing result for
users who come to Fedora from other distributions.
Rebooting automatically could also reduce the attack surface of an
instance that just came online since it would immediately reboot to
put all package updates into effect on the system. This reduces the
time that an unpatched instance is online prior to being fully
patched.
== Scope ==
* Proposal owners: This change is fairly isolated and only affects
Fedora cloud users who request package updates followed by a reboot in
their `cloud-init` metadata.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
Since this change only applies to `cloud-init` on the very first boot
of the instance, this wouldn't affect a user upgrading from one
version of Fedora to the next.
== How To Test ==
# Ensure you have a cloud image that has an update that needs a reboot
(kernel, openssl, etc)
# Boot an instance with the following `cloud-init` user data:
#cloud-config
package_update: true
package_upgrade: true
package_reboot_if_required: true
# Wait for the package updates to finish on the instance and verify
that it rebooted after updating
== User Experience ==
First, if a user never uses the `package_upgrade` and
`package_reboot_if_required` options in their `cloud-init` user data,
they won't be affected by this change. These options are not enabled
in `cloud-init` by default.
If a user does enable both of these options, they will see their cloud
instance come online, apply updates, and reboot if required. Most
cloud providers have very fast reboots, so the delay should not be a
problem.
== Dependencies ==
Nothing depends on this change.
== Contingency Plan ==
* Contingency mechanism: Push to Fedora 40 if the work cannot be done in time
* Contingency deadline: N/A
* Blocks release? N/A
== Documentation ==
Guidance for users in a blog post (Fedora Magazine) could be helpful
for this change. Many users might not be aware that they had the
option to ask for package updates and reboots via `cloud-init` for
their Fedora cloud instances.
== Release Notes ==
Fedora cloud instances now automatically reboot when a user requests
package updates followed by a reboot on the first boot of the
instance. The reboot only occurs if an updated package requires a
reboot to go into effect (such as a kernel or critical system
library).
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
10 months, 1 week
RISC-V -- are we ready for more, and what do we need to do it?
by Matthew Miller
Hi all! I just got back from Open Source Summit, several of the talks I
found interesting were on RISC-V -- a high-level one about the
organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official
Fedora arch. As I understand it, the major infrastructure blocker is simply
that there isn't server-class hardware (let alone hardware that will build
fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
as builders, could we build fast enough under QEMU emulation to work? We
have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of
the distro which don't build yet? Is there a big enough risc-v team to
respond to arch-specific build failures? And, do we have enough people to do
QA around release time?
* see http://fedora.riscv.rocks/koji/
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
10 months, 1 week
F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)
by Aoife Moloney
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 ==
This is the last step in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
effort. Jdks in fedora are already static, and we repack portable
tarball into rpms. Currently, the portbale tarball is built for each
Fedora and Epel version. Goal here is to build each jdk
(8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and
repack in all live fedoras.
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: jvanek(a)redhat.com
== Detailed Description ==
As described in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
during last year, packaging of JDKs had changed dramatically. As
described in same wiki page, and individual sub changes and devel
threads, with primary reason this - to lower maintenance and still
keep fedora java friendly.
* In first system wide change, we had changed JDKs to build properly
as standalone, portable jdk - the wey JDK is supposed to be built. I
repeat, we spent ten years by patching JDK to become properly dynamic
against system libs, and all patches went usptream, but it become
fight which can not be win
* as a second step we introduced portable rpms, which do not have any
system integration, only builds JDK and pack final tarball in RPM for
free use.
* In third step - without any noise, just verified with fesco -
https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
integrated rpms. Instead of this, normal RPMS BUildRequire portable
rpms and just unpack it, and repack it.
Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
oldest live Fedora, and repack everywhere. java-latest-openjdk, which
contains latest STS jdk - currently 20, soon briefly 21 and a bit
alter 22... Should be built in latest live EPEL - epel8 now. We have
verified, that such repacked JDKs work fine.
== Feedback ==
== Benefit to Fedora ==
java maintainers will finally some free time... No kidding -
maintenance and *certification* of so much supported JDKs on so much
Fedora versions is brutal. By building once, and repack, we will
regain cycles to continue support Fedora with all LTS and one STS
javas.
If we fail to build once and repack everywhere, java maintainers will
most likely need to lower the number of JDKs in fedora to system one
only.
== Scope ==
* Proposal owners: Technically all jdks (except 8, where some more
tuning is needed, and epels for java-latest) are prepared, as they
have portable version, and rpms just reapck it. Except tuning up the
jdk8 and epel for latest, scope owners are done.
* Other developers: There will be needed significant support from RCM
and maybe senior fedora leadership to help to finish the build in
oldest and enable to repack everywhere<!--
* '''Release engineering: [https://pagure.io/releng/issue/11438
#11438]''' There will be needed significant support from RCM, where
I'm actually unsure what they will have to do to enable this. The mas
rebuild will not be needed.
* Policies and guidelines: AFAIK none (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: All supported JDKS will remain
in Fedora in highest possible quality with full QA and certification,
and its packagers will not lose their minds. note, that QA will still
run on all live fedoras, not only on the builder one.
== Upgrade/compatibility impact ==
The change should be completely transparent to any user.
== How To Test ==
`sudo dnf update/install "java*"` will install expected set of working packages.
== User Experience ==
The change should be absolutely transparent to any user.
== Dependencies ==
To finish this we will need heavy support from RCM, and maybe others.
Although there are precedents with such package, they all bites. From
SW point of view, the dependence chain is `normal RPMs build requires
portable RPMs` and that's all.
== Contingency Plan ==
* Contingency mechanism: It should be stright forward to revert back
to building per OS
* Contingency deadline: N/A
* Blocks release? No. The change can be introduced even on the fly to
live distributions.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
10 months, 1 week
How to fix the "rpma.src: W: strange-permission rpma.spec 600"
warning?
by Xiao Yang
Hi all,
I try to create rpma source package on fedora by fedpkg --release rawhide mockbuild.
The permissions of original rpma.spec is 0644:
$ ll rpma.spec
-rw-r--r--. 1 mockbuild mock 2107 May 25 17:31 rpma.spec
The permissions of rpma.spec in the generated rpma source package is changed to 0600 and then the following warning is triggered by fedpkg --release rawhide lint.
$ fedpkg --release rawhide lint
Failed to get repository name from Git url or pushurl
Failed to get ns from Git url or pushurl
Mockbuild results directory found. Linting mockbuild results.
============ rpmlint session starts ================
rpmlint: 2.4.0
configuration:
/usr/lib/python3.11/site-packages/rpmlint/configdefaults.toml
/etc/xdg/rpmlint/fedora-legacy-licenses.toml
/etc/xdg/rpmlint/fedora-spdx-licenses.toml
/etc/xdg/rpmlint/fedora.toml
/etc/xdg/rpmlint/scoring.toml
/etc/xdg/rpmlint/users-groups.toml
/etc/xdg/rpmlint/warn-on-functions.toml
checks: 31, packages: 4
rpma.src: W: strange-permission rpma.spec 600
3 packages and 1 specfiles checked; 0 errors, 1 warnings, 0 badness; has taken 0.3 s
Could you tell me how to fix the warning?
Best Regards,
Xiao Yang
10 months, 2 weeks
Upcoming retirement of unused compat packages for Rust crates
by Fabio Valentini
Hi all,
I'm planning to do another round of removals of unused Rust crates -
at first. focusing only on compat packages which are no longer useful
since they have no remaining dependent packages in Rawhide.
This includes the gtk-rs v0.16 / gtk4-rs v0.5 compat packages:
- rust-atk0.16
- rust-atk-sys0.16
- rust-cairo-rs0.16
- rust-cairo-sys-rs0.16
- rust-gdk0.16
- rust-gdk-sys0.16
- rust-gdk-pixbuf0.16
- rust-gdk-pixbuf-sys0.16
- rust-gio0.16
- rust-gio-sys0.16
- rust-glib0.16
- rust-glib-sys0.16
- rust-glib-macros0.16
- rust-gobject-sys0.16
- rust-graphene-rs0.16
- rust-graphene-sys0.16
- rust-gtk0.16
- rust-gtk-sys0.16
- rust-gtk3-macros0.16
- rust-pango0.16
- rust-pango-sys0.16
- rust-pangocairo0.16
- rust-pangocairo-sys0.16
- rust-gdk4_0.5
- rust-gdk4-sys0.5
- rust-gsk4_0.5
- rust-gsk4-sys0.5
- rust-gtk4_0.5
- rust-gtk4-sys0.5
- rust-gtk4-macros0.5
- rust-libadwaita0.2
- rust-libadwaita-sys0.2
Side note: The compat packages for the even older gtk-rs v0.15 /
gtk4-rs v0.4 / libadwaita-rs v0.1 cannot be removed yet, since
squeekboard and system76-keyboard-configurator still depend on these
obsolete versions ... :sad face:
Additional (unrelated to gtk-rs) compat packages which are no longer needed:
- rust-libudev0.2
- rust-memmap2_0.3
- rust-cargo_metadata0.12
- rust-tui0.9
- rust-ansi-str0.5
All listed packages are compat packages with newer versions of these
projects already being available in Fedora 37+, and all listed
packages have no dependent packages left. If anybody has objections to
retiring any of these packages despite this, please notify me within
the next 7 days, as I plan to process the retirement of all packages
listed in this email next Monday (June 5).
Fabio
10 months, 2 weeks
F39 Change Proposal: Aspell Depreciation (Self-Contained Change)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/AspellDeprecation
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 ==
Deprecating aspell package because there are better-supported spell
checkers like hunspell/enchant2 which could be used instead. It also
has an upstream with almost 4 years of no action.
== Owner ==
* Name: [[User:ljavorsk| Lukas Javorsky]]
* Email: ljavorsk(a)redhat.com
== Detailed Description ==
Upstream of the aspell package has been inactive for almost 4 years
now. Most of the packages that have been using aspell in the past did
migrate to the supported [https://github.com/hunspell/hunspell
hunspell package] or any other spell checker.
The plan is simple:
1) Deprecate aspell package.
2) Create Bugzilla tracker to request all packages to be migrated to
the hunspell or any other spell checker (let maintainers choose their
preferred one).
3) After all of the packages have been migrated, create a Change to
retire aspell from Fedora
== Feedback ==
Early feedback from the community is located in this
([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Devel list announce])
== Benefit to Fedora ==
Fedora shouldn't maintain a dead package. This change will ensure
Fedora has relevant and upstreamed packages in it's repositories.
== Scope ==
* Proposal owners: Package aspell will be deprecated and the migration
request will be filled as a Bugzilla to all dependent packages
* Other developers: Migrate to hunspell package or any other supported
spellchecker present in Fedora repositories.
* Release engineering: No action required
* 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 ==
As this is only deprecation change, nothing will need to be handled
manually. The dependent packages will migrate to hunspell or any other
supported spellchecker present in Fedora repositories.
== How To Test ==
== User Experience ==
== Dependencies ==
List of the packages from Fedora 39
=== Requires ===
repoquery -q --repo=rawhide{,-source} --whatrequires 'aspell*' | grep
-v '^aspell' | grep -v 'src$' | pkgname
eiskaltdcpp-qt
enchant-aspell
enchant2-aspell
kf5-sonnet-core
kf5-sonnet-core
moodle
perl-Code-TidyAll
perl-Text-Aspell
php-pspell
qa-tools
recoll
recoll
xedit
xmlcopyeditor
yagf
=== BuildRequires ===
repoquery -q --repo=rawhide{,-source} --whatrequires 'aspell*' | grep
-v '^aspell' | grep 'src$' | pkgname
eiskaltdcpp
enchant
enchant2
hunspell-az
hunspell-csb
hunspell-de
hunspell-en
hunspell-fa
hunspell-gv
hunspell-ky
ibus-typing-booster
inkscape
kf5-sonnet
logjam
perl-MouseX-ConfigFromFile
perl-MouseX-Types-Path-Class
perl-Text-Aspell
perl-Text-SpellChecker
PHP
recoll
tin
xmlcopyeditor
yagf
== Contingency Plan ==
* Contingency mechanism: No contingency mechanism is required for deprecation.
* Contingency deadline: Beta freeze
* Blocks release? No
''NOTE: If we don't finish this change by the deadline, it is possible
to just complete this change with the next release.''
== Documentation ==
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
10 months, 2 weeks
Are we ready for ipv6-mostly networks?
by Petr Menšík
Hello everyone,
I have attended recently csnog.eu conference [1], where some interesting
presentations took place. They were usually in Czech, so it is not
something I am going to share more. But what took my interest were ipv6
readiness with some exceptions. Fedora is ready to be run on dual-stack
IPv4 and IPv6 networks just fine. But the presentation were about future
case where we run most hosts on IPv6 network only, but allow some older
devices to take and use also IPv4 address.
Fortunately there is roughly the same presentation[2] in English, which
took the place on RIPE 85 meeting. What catched my interest were talk
about Windows 11 and Apple systems are ready, but not really talk about
how any linux distribution is ready for such situation. It seems to me
we should improve the support for mentioned mechanisms in Fedora.
What do you think about it?
[1] https://indico.csnog.eu/event/13/contributions/121/
[2] https://ripe85.ripe.net/archives/video/923/
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
10 months, 2 weeks
F39 Proposal: Make Toolbx a release-blocking deliverable and have
release-blocking test criteria (System-Wide Change)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker
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 ==
Up to date [https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] [https://opencontainers.org/ OCI] images must be
published on [https://registry.fedoraproject.org/
registry.fedoraproject.org] as release-blocking deliverables, and
there must be release-blocking test criteria to ensure usable
[https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs.
== Owner ==
* Name: [[User:Rishi|Debarshi Ray]], [[User:Sumantrom|Sumantro Mukherjee]]
* Email: debarshir(a)redhat.com, sumukher(a)redhat.com
== Detailed Description ==
Currently, there is no formal requirement for
[https://containertoolbx.org/ Toolbx] to be usable when a new Fedora
is released. This is a problem for a tool that's so popular and
provides something as fundamental as an interactive command line
environment for software development and troubleshooting the host
operating system. This Change aims to address this.
Toolbx has two parts — an [https://opencontainers.org/ OCI] image,
which defaults to
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] on Fedora hosts, and the
[https://src.fedoraproject.org/rpms/toolbox toolbox] RPM. The OCI
image is pulled by the RPM to set up a containerized interactive CLI
environment.
First, we want to ensure that there are up to date
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] OCI images published on
[https://registry.fedoraproject.org/ registry.fedoraproject.org] as
release-blocking deliverables at critical points in the development
schedule, just like the installation ISOs for the Editions from
[https://download.fedoraproject.org/pub/fedora/linux/releases/
download.fedoraproject.org]. This must at least happen when an
upcoming Fedora release is branched from Rawhide, and for the Beta and
Final release candidates. If possible, they should be updated more
frequently as part of the nightly composes. We do not expect this to
happen after a Fedora release has gone GA.
Second, we want to have release-blocking test criteria to ensure
usable [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs at
critical points in the development schedule. This must be used to
ensure that both changes in the Toolbx stack, and future
[https://docs.fedoraproject.org/en-US/program_management/changes_policy/
Changes] in other parts of the OS do not break Toolbx, and at least
cover the Beta and Final release candidates.
Examples of changes in the Toolbx stack causing breakage can be
[https://bugzilla.redhat.com/show_bug.cgi?id=2183034 FUSE] preventing
RPMs with file capabilities from being installed inside Toolbx
containers, Toolbx [https://github.com/containers/toolbox/issues/643
bind mounts] preventing RPMs with <code>%attr()</code> from being
installed or causing
[https://bugzilla.redhat.com/show_bug.cgi?id=2188304
systemd-tmpfiles(8)] to throw errors, etc.. Examples of changes in
other parts of the OS can be changes to Fedora's Kerberos stack
causing Kerberos to stop working inside Toolbx containers,
[[Changes/EnableSysctlPingGroupRange|changes]] to the
<code>sysctl(8)</code>
[https://github.com/systemd/systemd/commit/90ce7627dfe824ff6e7c0ca5f96350f...
configuration] breaking ping(8), changes in
[https://github.com/containers/toolbox/issues/562 Mutter] breaking
graphical applications, etc..
Note that having release-blocking test criteria for the
<code>toolbox</code> RPM will also implicitly test the
<code>fedora-toolbox</code> image.
== Feedback ==
== Benefit to Fedora ==
This Change improves the quality of the containerized interactive
command line [https://containertoolbx.org/ Toolbx] environments on
Fedora by adding formal requirements to ensure that they are usable
when a new Fedora is released. This will bring them closer to the
reliability of similar environments running directly on the host
operating system.
Toolbx is installed by default on CoreOS, Silverblue and Workstation.
It is indispensable for software developers using Silverblue to bypass
the difficulty of setting up a development environment in the usual
way. It is widely used, even on Workstation, by those who don't want
to pollute their host OS, or want to access a CLI environment that's
different from the host's without installing a virtual machine, or
want a pre-configured development environment.
It will be beneficial to consider the
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] images as release-blocking deliverables because
Fedora's [https://opencontainers.org/ OCI] infrastructure is often
broken. Here are [https://pagure.io/releng/issue/11092 two]
[https://pagure.io/releng/issue/11367 recent] examples of <code>fedpkg
container-build</code> not working. In the second case, it was
preventing the images from being rebuilt to pull in an
[https://bugzilla.redhat.com/show_bug.cgi?id=2170878 important]
bug-fix. The broken infrastructure prevents regular Fedora
contributors from jumping in to rebuild and publish the images at
critical points in the development schedule. Making them
release-blocking deliverables would attract greater attention and
scrutiny from release engineering and ensure that a Fedora development
cycle does not proceed with broken or outdated or missing
<code>fedora-toolbox</code> images.
At the moment, the branching of an upcoming Fedora release from
Rawhide is a particularly chaotic time. Since the
<code>fedora-toolbox</code> images for Fedora Branched and Rawhide are
not rebuilt as part of the branching process, there is a lot of
confusion for end-users until someone manually rebuilds the images and
gets them published, which can take some time as described above.
Having the images built and published by release engineering as part
of the branching will avoid this.
If someone installs the Beta or the Final on their host, and creates a
Toolbx container using the default <code>fedora-toolbox</code> image,
then, barring exceptions, the host and the container will have the
same RPM versions. Just like Workstation and Silverblue are released
with the same versions. This will ensure greater consistency in terms
of bug-fixes, features and pending updates.
Last but not the least, we cannot have release-blocking test criteria
for the [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs
unless the images are also release-blocking deliverables, because the
RPMs depend on the images. This brings us to the benefits of the
second part of this Change.
It will be beneficial to have release-blocking test criteria for the
[https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs because they
interact with different parts of the OS to set up the containerized
interactive CLI environments. These environments have seamless access
to the user’s home directory, the Wayland and X11 sockets, networking
(including Avahi), removable devices (like USB sticks), systemd
journal, SSH agent, D-Bus, ulimits, /dev and the udev database, etc.,
and any unexpected change in another part of the OS can break the
environment.
The release-blocking test criteria will be a way to co-ordinate
several disparate groups of developers to ensure that the
containerized interactive CLI Toolbx environments on Fedora are just
as reliable as those running directly on the host OS.
== Scope ==
* Proposal owners: Write down the release-blocking test criteria for
the [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs that
will be used for testing and the blocker bugs process.
* Other developers: The release-blocking test criteria for Toolbx will
require others to debug and fix bugs, possibly blockers, and be
mindful of making changes to other parts of the operating system that
break the Toolbx environment.
* Release engineering: [https://pagure.io/releng/issue/11399 #11399]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: [https://pagure.io/Fedora-Council/tickets/issue/449 #449]
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
This is only a change to the Fedora release processes. Therefore,
systems with a previous version of Fedora won't need any manual
intervention.
There should not be any user-visible change, other than, barring
exceptions, the
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] image having the same RPM versions as the host at
critical points in the development schedule, fewer bugs and a more
reliable Toolbx.
== How To Test ==
Up to date [https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] images must be available from
[https://registry.fedoraproject.org/ registry.fedoraproject.org] when
an upcoming Fedora release is branched from Rawhide, and for the Beta
and Final release candidates. The following steps can be used to test
this:
* Check the Toolbx containers and images present locally using
<code>toolbox list</code>.
* Remove any Toolbx containers and images for the Fedora release under
development using <code>toolbox rm</code> and <code>toolbox
rmi</code>.
* Create a new Toolbx container with <code>toolbox create</code> and
enter it with <code>toolbox enter</code>.
* Use <code>sudo dnf update</code> inside the Toolbx container.
Barring exceptions, the container should have the same RPM versions as
the host.
The [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs must
satisfy the test criteria for the Beta and Final release candidates.
Writing the test criteria is part of this Change, so they don't exist
at the moment, but likely examples can be:
* Graphical Apps running inside Toolbx container should be accessible outside
* Graphical Apps (text editors) should retain their state even when
the virtual terminal is closed
== User Experience ==
This Change improves the quality of the containerized interactive
command line Toolbx environments on Fedora by ensuring that they are
just as reliable as those running directly on the host operating
system.
If someone installs the Beta or the Final on their host, and creates a
Toolbx container using the default
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] image, then, barring exceptions, the host and the
container should have the same RPM versions. Just like Workstation and
Silverblue are released with the same versions. This will ensure
greater consistency in terms of bug-fixes, features and pending
updates.
== Dependencies ==
N/A (not needed for this Change)
== Contingency Plan ==
* Contingency mechanism: If there are no up to date
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] images published on
[https://registry.fedoraproject.org/ registry.fedoraproject.org] as
release-blocking deliverables, then the release-blocking test criteria
for the [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs
cannot be put into production. In that case this Change cannot be
implemented and status quo will be maintained. If the images get
published, but the test criteria is absent, then only the first half
of the Change will be implemented, and users can still benefit from
the more predictably updated images.
* Contingency deadline: We need this by the Change completion deadline
or before Fedora 39 is branched from Rawhide, whichever is earlier. As
per the [https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
schedule], both of those are currently set to happen on the 8th of
August 2023.
* Blocks release? No
== Documentation ==
* Toolbx basics: https://containertoolbx.org/install/
* Toolbx manuals: https://github.com/containers/toolbox/tree/main/doc
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
10 months, 2 weeks
