Now that we have foremanctl 1.0 published, it’s time to start the planning on how the images are going to be built, specifically in the modern era of supply chain awareness, we have the opportunity to skip build with only Podman/Buildah/Docker and shipping to one registry. We have solutions that can ensure and attest our build by providing provenance[1] .
Proposal
Following our current build process for RPMs, where we build using the copr project provided by Fedora, I want to propose that we use the Fedora Community solution to build container Images Konflux[2].
Konflux allows us to build images for PRs, manages the software dependencies in a fashion that resembles dependabot[3], pipelines are written using Tekton[4], all these technical details will be transparent for our users, with the heavy lifting being only on us(developers) that work in the build side of Foreman.
Currently, our containers rely on RPM packages. As the project expands and new packages are introduced, this approach leads to accumulating technical debt. We plan to transition from traditional packages to source-based containers in the future. This shift would ensure seamless integration between developers working on Foreman/Katello and our release process, making the images easily reproducible. Implementing Konflux will accelerate this transition from RPM to source-based releases, improving reproducibility.
Right now we have one tenant allocated to us in the Fedora Konflux Instance[5], to access the cluster interface it’s necessary to have one Fedora Account and have the RBAC permission set in the tenant-config.
While I’m not opposed to source based releases, I hope that the effort can be split into 2 parts. One to start using Konflux with RPMs, then migrate to source based containers. Right now we have a lot that still depends on the packages and as a project we need to provide a path from packages to containers. That could very well be a Foreman 4.0 release item. I’d also like to avoid parallel maintenance of RPMs and containers. If we tie the Konflux effort to source based containers it’ll take a long time to really adopt it.
Totally, I don’t want to be the one that drops traditional packaging, specially with all the knowledge/tooling that we created in the last decade, but I also want to use the source based containers approach to increase the speed that we delivery container images, instead of waiting for the regular .deb/rpm release and branching, this would result in us having parallel releases for different types of delivery.
I’m not exactly sure what the RFC intends to deliver. A more concrete goal will make it easier to comment.
I’d like to avoid diverging containerized and non-containerized installations. Our whole toolchain isn’t ready for it and I think the reproducibility will be hard to realize.
For example, core Foreman may allow a newer dependency than what a plugin allows. Then you need to pin things (example in Debian), but where would you do that? Where would you store lockfiles if they will depend on exactly the combination of plugins you build in the container?
We also do have some patches in our RPM packaging to exclude a bunch of files to make runtimes smaller.
My preference is that short term it’s explicitly NOT a goal to deliver source based containers but instead to focus on a proper delivery pipeline for our container images (candlepin-oci-images, foreman-oci-images & pulp-oci-images) since that’s what we consume in foremanctl.
