F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx, sumukher@xxxxxxxxxx



== 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/90ce7627dfe824ff6e7c0ca5f96350fbcfec7118
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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux