On Mon, May 29, 2023 at 8:16 AM Debarshi Ray via devel <
devel@lists.fedoraproject.org> wrote:

> Hey Owen,
>
> On Wed, 2023-05-24 at 13:50 -0400, Owen Taylor wrote:
> >
> > What if we made the Toolbox container image just one more base image
> > and built it with ImageFactory?
> >
> >  - Integrated into the compose process
> >  - Across all architectures
> >  - No OSBS dependency
> >
> > The main disadvantage is that it is no longer layered, so *if* you
> > happen to have the exact same Fedora image version around for some
> > other reason (a big if), you save a fraction of space:
> >
> > Fedora 38 container - 71M compressed, 201M uncompressed
> > Toolbox add-on layer -  232M compressed, 753M uncompressed
> > Toolbox squashed  - 291M compressed, 884M uncompressed
>
> I am not too attached to the bandwidth or space savings due to the
> fedora-toolbox image being a layered image.
>
> [ In future, I would like to  explore if we can ship the fedora-toolbox
> image as part of the Silverblue and Workstation ISOs, to avoid the need
> for a sizable download just to set up the default Toolbx.  That could
> unlock things like defaulting to a Toolbx shell or generally help
> promoting Toolbx as a primary interactive CLI environment.  Anyway,
> that's a big 'if'.  ]
>
> 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, but maybe
that's bearable if we can substantially improve the workflow?

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.

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?

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.

- Owen
_______________________________________________
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

Reply via email to