On Mon, May 29, 2023 at 8:16 AM Debarshi Ray via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> 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@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
