On 2023-05-05 09:01:01 -0400 (-0400), Neal Gompa wrote: [...]
I'm confused why you're mirroring Fedora repos and building custom Fedora images. Is there something we could do on the Fedora Cloud side to make this workload easier? We already produce OpenStack-targeted Fedora Cloud images, as an example. [...]
There are two main reasons: First, we want the images to be as minimal as possible. Take DevStack-based test jobs for example, they use pip to install Python libraries into the system context, and so any preinstalled distribution packages of Python libraries can cause conflicts which are hard to mitigate. This is, for example, a big part of why we developed our own minimal alternative to cloud-init (glean). If we used pre-built images we'd still need to maintain a cross-distro toolchain capable of altering images in order to cleanly uninstall packages which could cause conflicts. Second, in order to speed up jobs, we pre-cache a lot of content onto the images we build (Git repositories for projects, frequently downloaded files like CirrOS images, et cetera). This means that, at a minimum, we need to maintain a cross-distro toolchain capable of altering images in order to embed the cache, so building the images from scratch isn't a major leap past there. Also, bear in mind that building the images isn't all of the problem with fast-moving/short-support distros like Fedora (or SUSE Tumbleweed, or Debian Sid, or non-LTS Ubuntu versions, or...). It's that projects want to freeze their testing for stable branches at release time, and continue to use versions contemporary to those releases for the support timeframe of the stable branch, which in OpenStack's case is measured in years. In theory we could continue testing OpenStack stable branches on old Fedora versions, but there comes a point in time where Fedora mirrors drop the packages for those versions, or they cease to be viable in our donated cloud environments for other reasons. The crux of the matter is that we've built our CI platform (and OpenStack's support model for that matter) around the idea of testing software for deployment on LTS "server" distributions, and have made choices which optimize for those cases at the expense of not being able to as easily track the "bleeding edge" distributions. -- Jeremy Stanley