From Fedora Project Wiki

Revision as of 13:17, 20 April 2023 by Rishi (talk | contribs) (FInish benefits)


Make Toolbx a release-blocking deliverable and have blocking test criteria

This is a proposed Change for Fedora Linux.
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 fedora-toolbox OCI images must be published on registry.fedoraproject.org as release-blocking deliverables, and there must be release-blocking test criteria to ensure usable toolbox RPMs.

Owner

Current status

  • Targeted release: Fedora Linux 39
  • Last updated: 2023-04-20
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Currently, there is no formal requirement for 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 OCI image, which defaults to fedora-toolbox on Fedora, and the toolbox RPM. The OCI image is pulled by the RPM to set up an interactive CLI environment within a container.

First, we want to ensure that there are up to date fedora-toolbox OCI images published on registry.fedoraproject.org as release-blocking deliverables at critical points in the development schedule, just like the installation ISOs for the Editions from 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 toolbox RPMs at critical points in the development schedule. This must be used to ensure that both changes in the Toolbx stack, and future Changes in other parts of the OS do not break Toolbx, and at least cover the Beta and Final release candidates.

One example of a change in the Toolbx stack causing breakage is FUSE preventing RPMs with file capabilities from being installed inside Toolbx containers. 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 to the sysctl(8) configuration breaking ping(8), changes in Mutter breaking graphical applications, etc..

Note that having release-blocking test criteria for the toolbox RPM will also implicitly test the fedora-toolbox image.

Feedback

Benefit to Fedora

This improves the quality of the containerized interactive command line 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 those 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 fedora-toolbox images as release-blocking deliverables because Fedora's OCI infrastructure is often broken. Here are two recent examples of fedpkg container-build not working. In the second case, it was preventing the images from being rebuilt to pull in an 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 fedora-toolbox images.

At the moment, the branching of an upcoming Fedora release from Rawhide is a particularly chaotic time. Since the fedora-toolbox 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. 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 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.

Last but not the least, we can not have release-blocking test criteria for the 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 toolbox RPMs because they interact with different parts of the OS to set up the containerized interactive CLI environments. Toolbox 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 Toolbx environments on Fedora are just as reliable as those running directly on the host OS.

Scope

  • Proposal owners:
  • Other developers:
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Community Initiatives:

Upgrade/compatibility impact

How To Test

User Experience

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? No


Documentation

N/A (not a System Wide Change)

Release Notes