On Thu, Apr 3, 2025, at 5:10 AM, Adam Samalik wrote:
On Tue, 1 Apr 2025 at 17:11, Colin Walters walters@verbum.org wrote:
Hi Adam, thanks for your reply.
On Mon, Mar 31, 2025, at 4:47 AM, Adam Samalik via devel wrote:
On Fri, 28 Mar 2025 at 18:55, Colin Walters walters@verbum.org wrote:
Hi, I'd like to make progress on this: https://gitlab.com/redhat/centos-stream/containers/bootc/-/issues/1174
How are you building the images?
Note these are container images, not disk images - and those are very different things.
Meaning the container images you can customise with podman, and then build to actual qcow or whatever you need, and deploy. Correct?
Yep. A lot more at https://docs.fedoraproject.org/en-US/bootc/ - this is about the build process for what is currently https://quay.io/centos-bootc/centos-bootc:$stream (which we also after this we should move to quay.io/centos but that's a distinct task).
All of us here probably saw the discussions about Konflux on Fedora Discourse and devel list. Red Hat is clearly trying to move all of the building to Konflux, including RHEL. And because CentOS Stream is where RHEL development happens publicly, we can only expect Konflux coming to CentOS Stream as well.
+1
So I've already opened a general tracker about that: https://issues.redhat.com/browse/CS-2709 and will be defining what that means for CS very soon.
So if you already made it work in Konflux, why don't we use that for the CS builds also? That could be one of the first things CS builds in Konflux.
Definitely. Note there is parallel discussion and work happening for this in Fedora at the moment as well (linked from the centos ticket is https://gitlab.com/fedora/bootc/base-images/-/merge_requests/148 )
Based on the ticket you linked, you want to make it part of the primary composes, and have an image built with every compose. I agree that would be great. How could we make that work?
Do you see pungi triggering Konflux somehow, and retrieving the artifacts from it? Similarly to how it happens with Koji now?
This I think is most practical.
Or would you like to skip pungi completely, and just trigger Konflux builds in sync with our production composes? And somehow ensure the same package set is used etc.?
Well, that's what we do today, just not quite accurately. But there's two important and related sub-threads here:
- The compose should (soft) fail if the base image build fails - Branching (rare as it is) and other release-engineering activity naturally follows if it comes from pungi triggers rather than a distinct asynchronous process that the main ops/releng team has less awareness of.
I do have a bigger goal from this that may illuminate things more, which is https://github.com/rhinstaller/anaconda/discussions/5888 (L;DR we change from - rpms -> (lorax/image builder) -> ISO to - rpms -> bootc container -> derived anaconda container -> (lorax/image builder) -> ISO image
Crucially, doing things that intermediate way means it's as easy as making derived containers to make arbitrary custom ISOs.