<@walters:fedora.im>
15:01:59
!startmeeting bootc (2025-05-13)
<@meetbot:fedora.im>
15:02:00
Meeting started at 2025-05-13 15:01:59 UTC
<@meetbot:fedora.im>
15:02:01
The Meeting name is 'bootc (2025-05-13)'
<@dustymabe:matrix.org>
15:02:21
!hi
<@zodbot:fedora.im>
15:02:24
Dusty Mabe (dustymabe) - he / him / his
<@snthrailkill:matrix.org>
15:02:43
!hi
<@rsturla:fedora.im>
15:02:45
!hi
<@zodbot:fedora.im>
15:02:46
Sean Thrailkill (snthrailkill)
<@zodbot:fedora.im>
15:02:47
None (rsturla)
<@dustymabe:matrix.org>
15:02:53
sorry I missed the meeting last week. Had some nasty sickness. I did watch the recording and appreciate the discussion.
<@jeckersb:fedora.im>
15:03:04
!hi
<@zodbot:fedora.im>
15:03:06
John Eckersberg (jeckersb)
<@hricky:fedora.im>
15:03:10
!hi
<@zodbot:fedora.im>
15:03:11
Hristo Marinov (hricky) - he / him / his
<@walters:fedora.im>
15:03:32
!hi
<@zodbot:fedora.im>
15:03:33
Colin Walters (walters)
<@walters:fedora.im>
15:03:50
OK so I am not sure we had an agenda for this one yet? The last image building meeting indeed had a lot of content.
<@walters:fedora.im>
15:04:03
dustymabe: hope you feel better! Do you or anyone else have any followup additional from that?
<@dustymabe:matrix.org>
15:04:50
I don't have anything right now. I think the biggest takeaway for the CoreOS side is just knowing where to focus our attention next.
<@dustymabe:matrix.org>
15:05:23
IIUC bootc-image-builder is the short term thing to target, but image-builder-cli is the project to watch for longer term use.
<@dustymabe:matrix.org>
15:05:45
so we'll keep abreast of both probably as we start down this path
<@walters:fedora.im>
15:06:34
Well, I am not sure I'd put it quite that way given that as far as I know at least e.g. rhel is on track to ship b-i-b so if by "short" you mean "lifecycle of rhel10" then I guess? =)
<@dustymabe:matrix.org>
15:06:54
correct.
<@jbtrystram:matrix.org>
15:06:55
!hi
<@zodbot:fedora.im>
15:06:57
Jean-Baptiste Trystram (jbtrystram) - he / him / his
<@walters:fedora.im>
15:07:26
I do kind of have a feeling that ultimately the custom-coreos-disk images use case basically needs to end up as a wrapper anyways
<@dustymabe:matrix.org>
15:08:08
Yeah. I would think `custom-coreos-disk-images` repo goes away.
<@walters:fedora.im>
15:09:14
Alex also filed https://github.com/bootc-dev/bootc/issues/1316 as followup
<@walters:fedora.im>
15:10:34
OK, did anyone else have topics they wanted to bring up? We didn't come with a preset agenda
<@rsturla:fedora.im>
15:10:56
I believe Sean Thrailkill wanted to discuss a bit about the testing workflow?
<@snthrailkill:matrix.org>
15:11:41
Hey guys. We had some chatter in some channels about people wanting to be able to not just test their image using CI but also locally.
<@snthrailkill:matrix.org>
15:12:16
Then there's a separate concern of testing a VM of the image, using QEMU or something. Again both locally and in CI
<@snthrailkill:matrix.org>
15:12:31
I think it would be helpful if we could come up with some examples about how to go about this
<@snthrailkill:matrix.org>
15:12:46
So far I've only seen Martin Pitts work for Cockpit
<@walters:fedora.im>
15:13:07
https://gitlab.com/fedora/bootc/tracker/-/issues/2 I think is the overall tracker for this, a whole lot of links from there.
<@snthrailkill:matrix.org>
15:13:55
Yeah I saw it. Looks great. Never used COSA but the idea sounds on the right path.
<@walters:fedora.im>
15:15:22
But on this topic I did just post in the fedora-bootc chat about https://github.com/cgwalters/cstor-dist and I see it as an extremely useful piece in the puzzle here and I am hoping to build some momentum in the coming months around centralizing some of the wrapper tools around install/test workflows. (For example https://github.com/ublue-os/bluefin-lts/blob/main/Justfile is cool but has the downside of users forking it by default, and cstor-dist completely sidesteps the `rootful_load_image` problem)
<@snthrailkill:matrix.org>
15:16:19
Yeah I saw your message in the channel this morning. I'm happy to help test this for you.
<@rsturla:fedora.im>
15:17:57
I too am not familiar with COSA, but I'll give my overall thoughts on testing.
<@rsturla:fedora.im>
15:17:57
The first being "What's on the OCI image?" and the second being "How does this function on a booted system?".
<@rsturla:fedora.im>
15:17:57
There's two parts to "testing" I can think of in this context.
<@rsturla:fedora.im>
15:17:57
<@rsturla:fedora.im>
15:18:24
The former is quite easy to do by gaining shell on the OCI via "podman run", or through built-in checks in "bootc container lint".
<@rsturla:fedora.im>
15:18:24
I've used Terratest to automate this in the past, which is a Go tool, but I'm sure it's just as possible with plain Bash or manual.
<@rsturla:fedora.im>
15:18:24
<@rsturla:fedora.im>
15:18:24
<@rsturla:fedora.im>
15:19:50
Colin's repo allows you to go from a regular Everything ISO to a booted system via the (possibly now slightly more legacy?) "ostree container" commands. Though I saw there's new integrations in Anaconda to allow using bootc directly
<@rsturla:fedora.im>
15:19:50
The latter is more involved, but Colin's new repo certainly helps streamline this. You can either use something like Bootc Image Builder to create the QCow2 image and boot into that. BIB has automation for an unattended installation.
<@rsturla:fedora.im>
15:20:37
The latter is more involved, but Colin's new repo certainly helps streamline this. You can either use something like Bootc Image Builder to create the QCow2 image and boot into that. BIB has automation for an unattended installation.
<@rsturla:fedora.im>
15:20:37
Colin's repo allows you to go from a regular Everything ISO to a booted system via the (possibly now slightly more legacy?) "ostree container" commands. Though I saw there's new WIP integrations in Anaconda to allow using bootc directly
<@walters:fedora.im>
15:21:10
The anaconda thing is indeed tracked by https://github.com/rhinstaller/anaconda/discussions/5197 but basically what we ended up doing is teaching the anaconda -> ostree code to detect when it's bootc and do bootc things (like kargs and LBIs) so we've managed to basically not *need* a new bootc verb other than cosmetics
<@rsturla:fedora.im>
15:22:12
Possibly a different discussion, but I'd be curious to know how this would work alongside the proposed composefs backends, given it seems to be very much tailored to ostree
<@walters:fedora.im>
15:23:19
There's some detail to that but largely I think we can make a lot of that work without changes to anaconda
<@walters:fedora.im>
15:24:13
Sean Thrailkill: An overall challenge in these discussions though is that some people will have very different preferred environments and flows; some orgs/people will be cloud-first, others will be local-first (and that bifurcates to linux/macos or even windows)
<@snthrailkill:matrix.org>
15:25:23
Absolutely agreed. And while we don't need a single solution that covers all areas for both environments I do think it's worth while showing examples of both for whoever is trying to use Bootc. Im seeing more people trying to use local first than I anticipated.
<@snthrailkill:matrix.org>
15:26:22
I'll start playing with your stuff over the next week and see if I can put together a good example
<@walters:fedora.im>
15:29:29
(sorry, had to context switch for a minute)
<@walters:fedora.im>
15:29:46
I'll edit the above issue to clarify the goal and better centralize the existing work
<@walters:fedora.im>
15:30:20
(ok just did)
<@walters:fedora.im>
15:31:10
I think technically we're past time, so we should probably close. Any last thoughts? Conversation can always continue in the existing async channels
<@rsturla:fedora.im>
15:31:31
Just a general request for making use of the "Good First Issue" labels across the related repos, as it's not easy to understand how complex a change is from just the name.
<@dustymabe:matrix.org>
15:31:46
Thanks for running the meeting Colin Walters
<@walters:fedora.im>
15:31:57
Thanks all for attending!
<@walters:fedora.im>
15:31:59
!endmeeting