Re: 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]

 




> On 8 May 2023, at 14:51, Aoife Moloney <amoloney@xxxxxxxxxx> 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: debarshir@xxxxxxxxxx, sumukher@xxxxxxxxxx
> 
> 
> 
> == 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@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
_______________________________________________
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