On Tue, May 30, 2023 at 9:47 AM Debarshi Ray <rishi...@lostca.se> wrote:
> 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@lists.fedoraproject.org> 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. :) > I guess in this scenario, the Fedora images are no longer the reference for creating things for other distributions and something else (RHEL, Ubuntu, ...) would have to take over that role. For "tweaking", I'd think we'd definitely want to promote "FROM fedora-toolbox:latest". > 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'? > I haven't actually tried building the Fedora container images locally, but it it looks relatively documented and straightforward, and someone could write a shell script to automate it pretty easily. But it is still going to require tools (ImageFactory) that people don't have installed and probably take a while to run. It seems like more of a "want to contribute to the the Fedora toolbox image" thing than a "would do it to run tests when contributing to Toolbx" thing. 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 > In this scenario the Fedora Toolbx image definition would live in fedora-kickstarts, so it doesn't really make sense for me that Toolbox CI would *recreate it*, rather than just using the version from the repository. Ideally, we'd run the Toolbox tests against the newly built Toolbx image as part of QE for the Fedora compose. > ... 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? > What I mean by this was simply the obvious - that the Toolbx image is built as part of the compose, and can be tested as part of the compose validation. That nobody is sitting there manually typing 'fedpkg container-build' and creating Bodhi updates. (*) - Owen (*) I'm not saying that this level of integration is impossible with OSBS - in fact there is some level of Pungi support for OSBS container builds already. Just that it's basically *already* there in Fedora for the base images.
_______________________________________________ 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
