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
