> On 8 May 2023, at 14:51, Aoife Moloney <amolo...@redhat.com> wrote: > > 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
This url does not exist. > 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: debars...@redhat.com, sumuk...@redhat.com > > > > == Detailed Description == > Currently, there is no formal requirement for > [https://containertoolbx.org/ Toolbx] to be usable when a new Fedora Nor this one. Barry > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
