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]

 



Hey Owen,

On Mon, 2023-05-29 at 12:39 -0400, Owen Taylor wrote:
> On Mon, May 29, 2023 at 8:16 AM Debarshi Ray via devel
> <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > 
> > My main concern, which I had brought up in the Release Engineering
> > tickets before [1,2] is whether the fedora-toolbox images would
> > continue to be defined as a Docker/Containerfile.  I am asking
> > because the fedora base images are defined as kickstart files [3].
> > 
> > There's some value in continuing to use a Docker/Containerfile
> > because it's widely known and leads to a common workflow.  It is
> > used for the official Toolbx images for other distributions like
> > Arch Linux, RHEL and Ubuntu, and a growing list of third-party
> > Toolbx images [4].  A Docker/Containerfile is easy to use with
> > 'podman build' as part of the upstream CI, which makes it easier to
> > test all the different parts.
> 
> Unfortunately, if we switched to using ImageFactory or pretty much
> anything other than OSBS, we'd no longer be able to define the Fedora
> toolbox image as a Dockerfile. It certainly is a disadvantage that
> it's no longer connected to the way that the other toolbox images are
> defined,

It's an advantage to have the Fedora images be defined in the same
source language as the Arch Linux and Ubuntu images, and certainly the
RHEL images.  However, ultimately, I see it only as a convenience. 
Folks can take the Fedora images as a reference and tweak them to fit
their own distribution, or copy paste the files across Git
repositories, etc..  If we lose that, then I would learn to live with
it.  :)

If we do move away from Container/Dockerfiles, then my main question
would be whether it'll still be easy to locally build the images.  Will
we need something a lot more elaborate than the simplicity of a 'podman
build'?

Toolbx has two parts.  A somewhat distro-agnostic toolbox(1) binary,
and an OCI image for a distribution.  Both work together to provide an
interactive CLI environment, and hence both should be tested together.

If a contributor attempts to change one or both of those two, then it
should be easy for them to verify whether both would continue to work
together.  Currently, they can do that by doing a local 'podman build'
on the image definitions in toolbox.git and try to use them with their
modified toolbox(1) binary.  I want to formalize this by making the
upstream CI run against both:
  (a) images that are currently published on the OCI registries and 
  (b) images that are built on-the-fly from the sources in toolbox.git

... so that it will validate any changes to the image sources in
toolbox.git, and alert us to any changes in the underlying distribution
(eg., packages, dependencies, base images, etc.) that could break
future image rebuilds.

Currently, the upstream CI runs only against (a).

If we lose the simplicity of a 'podman build' then we lose the testing.
That's my main worry.

If the new set-up offers a similarly simple way of building the images
from source, then I am happy.

> but maybe that's bearable if we can substantially improve the
> workflow?

The phrase "we can substantially improve the workflow" makes me
curious.  Any details or pointers?

> With some refactoring of the kickstarts for Fedora containers, we
> could also remove some of the hackiness in the Dockerfile where it is
> undoing choices in the base image.

*nod*

> When I ask this question, I do have a hidden agenda - I'm thinking
> that it might be possible to move Flatpak generation to a Koji plugin
> that runs directly on the builders, but that would leave the toolbox
> as the sole user of the OSBS cluster, which seems dubiously
> sustainable. So maybe we can take Toolbox off of OSBS as well and
> retire OSBS?

Yes, I saw you mention this elsewhere.  I totally understand and agree
with your motivation.  Trying to consolidate the infrastructure does
sound like a good idea.

> Now, if we could instead move to OSBS 2 and have that actively
> maintained and across architecture, that could be better, but I don't
> really see where the resources are going to come from to do that. 

*nod*

Cheers,
Rishi
_______________________________________________
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