Hi, I'd like to make progress on this: https://gitlab.com/redhat/centos-stream/containers/bootc/-/issues/1174
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? Are you able to use either Kiwi or Image Builder? We're working on adding their support to the CS Koji as we're looking into various ways to build images in general: https://issues.redhat.com/browse/CS-2746
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
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.
Are you able to use either Kiwi or Image Builder?
I'm pretty opposed to using either of those to generate container images as they stand today. We have invested in Konflux (which is Tekton) to build them currently.
However note the strategy for bootc is that we enable generating disk images from container images, and e.g. https://github.com/osbuild/bootc-image-builder exists (and is also shipped in RHEL) which uses some of the same Image Builder code under the hood. But we also directly support installing with Anaconda too as well as a "takeover" install via bootc install to-disk, so one doesn't always need to make disk images from the container images at all.
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?
Are you able to use either Kiwi or Image Builder?
I'm pretty opposed to using either of those to generate container images as they stand today. We have invested in Konflux (which is Tekton) to build them currently.
So, funny you mention Konflux!
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.
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.
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?
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.?
However note the strategy for bootc is that we enable generating disk images from container images, and e.g. https://github.com/osbuild/bootc-image-builder exists (and is also shipped in RHEL) which uses some of the same Image Builder code under the hood. But we also directly support installing with Anaconda too as well as a "takeover" install via bootc install to-disk, so one doesn't always need to make disk images from the container images at all.
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.
-
Adam Samalik -
Colin Walters