#meeting-1:fedoraproject.org log

<@jbrooks:matrix.org>

15:00:59

!startmeeting fedora_bootc_initiative

<@meetbot:fedora.im>

15:01:03

Meeting started at 2025-04-22 15:00:59 UTC

<@meetbot:fedora.im>

15:01:04

The Meeting name is 'fedora_bootc_initiative'

<@jeckersb:fedora.im>

15:01:52

!hi

<@zodbot:fedora.im>

15:01:54

John Eckersberg (jeckersb)

<@jbrooks:matrix.org>

15:02:15

!topic roll call

<@dustymabe:matrix.org>

15:02:44

!hi

<@zodbot:fedora.im>

15:02:51

Dusty Mabe (dustymabe) - he / him / his

<@jlebon:fedora.im>

15:02:58

!hi

<@zodbot:fedora.im>

15:02:59

None (jlebon)

<@jmarrero:matrix.org>

15:03:01

!hi

<@zodbot:fedora.im>

15:03:03

Joseph Marrero (jmarrero)

<@snthrailkill:matrix.org>

15:03:17

!hi

<@zodbot:fedora.im>

15:03:22

Sean Thrailkill (snthrailkill)

<@jeckersb:fedora.im>

15:03:35

(fyi Colin Walters is out today)

<@rsturla:fedora.im>

15:03:36

!hi

<@zodbot:fedora.im>

15:03:37

None (rsturla)

<@rriemann:kde.org>

15:03:39

!hi

<@zodbot:fedora.im>

15:03:41

Robert Riemann (rriemann) - he / him / his

<@jbrooks:matrix.org>

15:05:21

Dusty said he has a topic

<@dustymabe:matrix.org>

15:06:04

It's small :)

<@jbrooks:matrix.org>

15:06:37

I forget, with this new zodbot, do I need to make ppl chair?

<@dustymabe:matrix.org>

15:07:09

!topic develop tooling for browsing "stream" history

<@dustymabe:matrix.org>

15:07:26

!link https://gitlab.com/fedora/bootc/tracker/-/issues/65

<@dustymabe:matrix.org>

15:07:56

and now we have our answer :)

<@dustymabe:matrix.org>

15:09:23

<@dustymabe:matrix.org>

15:09:23

It would be nice if we had some way to browse the history and see what changes came in with each update.

<@dustymabe:matrix.org>

15:09:23

So this one is simple. With containers it's not super easy to see the meaningful history for a moving tag in a registry.

<@dustymabe:matrix.org>

15:09:46

This problem isn't specific to bootable containers, I think it would be useful for app containers too.

<@dustymabe:matrix.org>

15:10:34

I'm not necessarily suggesting that the container registry is no longer the source of truth. It just would be nice to have some other way to access the relevant information

<@rsturla:fedora.im>

15:10:39

Existing issues that could be somewhat related:

<@rsturla:fedora.im>

15:10:39

- https://github.com/bootc-dev/bootc/issues/932

<@rsturla:fedora.im>

15:10:39

- https://github.com/bootc-dev/bootc/issues/1004

<@jbrooks:matrix.org>

15:10:55

Did Valentin give a talk about something like this at the containerization guild?

<@snthrailkill:matrix.org>

15:12:15

I love the idea. Are you targeting a specific registry or anything first?

<@dustymabe:matrix.org>

15:12:16

Robert Sturla: nice

<@dustymabe:matrix.org>

15:12:35

Sean Thrailkill: not in particular

<@jlebon:fedora.im>

15:13:34

one random idea I had is that if you push versioned tags as well, then you can build a "history" by having each build reference as a LABEL the parent version

<@jlebon:fedora.im>

15:14:01

so that you're not constrained to a registry-specific API for querying tag information

<@jlebon:fedora.im>

15:14:05

so that you're not constrained to a registry-specific API for querying tag history information

<@dustymabe:matrix.org>

15:15:37

Yeah. Maybe that can be an optimization, but not a requirement?

<@jbrooks:matrix.org>

15:16:10

this was the Valentin talk I was thinking of: https://www.youtube.com/watch?v=GT8bNaeHuy8&t=1255s

<@snthrailkill:matrix.org>

15:17:54

Is this something that exists in any other form currently? I almost feel like container chnagelog is the first step that tools like renovate can pick up on. It would be able to create something like you have mocked out easily

<@dustymabe:matrix.org>

15:19:31

Jason Brooks: changelogs I think are not exactly what I was talking about, but do overlap heavily

<@dustymabe:matrix.org>

15:19:51

when I think of changelog I think of human readable text about the changes in the packages

<@dustymabe:matrix.org>

15:20:09

this is more of a "report about embedded content", which is very similar, but not exactly the same

<@dustymabe:matrix.org>

15:20:52

so for example. in FCOS today we have them combined (release notes & changed content) in:

<@dustymabe:matrix.org>

15:20:52

https://fedoraproject.org/coreos/release-notes?arch=x86_64&stream=stable

<@dustymabe:matrix.org>

15:20:52

<@dustymabe:matrix.org>

15:21:32

but the "builds browser" has a little more dry information (and also more links to useful things):

<@dustymabe:matrix.org>

15:21:32

<@dustymabe:matrix.org>

15:21:32

https://builds.coreos.fedoraproject.org/browser?stream=stable&arch=x86_64

<@dustymabe:matrix.org>

15:22:36

but yeah. if there is some automated way we can get changelog content (i.e. rpm change logs would be easiest) then we could display them too.

<@rsturla:fedora.im>

15:22:41

These SBOMs would be "attached" to each OCI image based on the image digest and you can compare the two JSON file contents to see the diffs.

<@rsturla:fedora.im>

15:22:41

<@rsturla:fedora.im>

15:22:41

There's not any decent tooling that exist currently for this sort of thing, but by comparing information extracted from SBOMs, you can receive the before and after information on a package level, including some non-packaged content (such as ELF binaries).

<@rsturla:fedora.im>

15:23:05

I'm not sure from the information from these SBOMs, if you can match them up with the RPM DB changelogs

<@jlebon:fedora.im>

15:23:50

Robert Sturla: i think the problem isn't necessarily the extracting of the metadata from the images, but getting that history perspective of what changed over time. basically: there is no git branch equivalent in the OCI world

<@rriemann:kde.org>

15:24:16

Producing consistently SBOM would also serve the compliance with NIS2. Unfortunately, the tooling is not very robust. Not all containerised OS are supported. Fedora is not for example.

<@snthrailkill:matrix.org>

15:24:47

Yeah Robert that's what I'm thinking. If we tie a SBOM through a label or something to an image then comparing the difference between them becomes feasible

<@rsturla:fedora.im>

15:24:52

Ah, understood. So the problem is more knowing that the image tagged with 20250422 was released before 20250423 (but also accounting for when the tagging standard isn't trivial)

<@rsturla:fedora.im>

15:26:08

Ah, understood. So the problem is more knowing that the image tagged with 20250422 was released before 20250423 (while also accounting for when the tagging standard isn't trivial)

<@jlebon:fedora.im>

15:26:46

yeah, this is why i mentioned https://matrix.to/#/!YWqcsiUQiCaqimYdQT:fedoraproject.org/$rg8pieVbdJH4PUCIyKP4bWUU25394CHD7IpB1eHXToc?via=fedoraproject.org&via=fedora.im&via=matrix.org

<@jlebon:fedora.im>

15:27:13

basically, you can have a moving tag and versioned tags, and the tooling doesn't actually have to understand your particular versioning scheme. it just follows LABELs

<@dustymabe:matrix.org>

15:27:32

ehh. it's not even that.

<@dustymabe:matrix.org>

15:27:32

<@dustymabe:matrix.org>

15:27:32

it's that trying to find out what changed in the latest build is kind of hard to do right now

<@snthrailkill:matrix.org>

15:27:37

Hmm. Maybe a label thats ISO-8601 compliant to say when it was published? Then we make a tool that knows what tag to look for between 2 images and periodically checks a registry?

<@dustymabe:matrix.org>

15:27:41

first you have to find what the previous build was

<@dustymabe:matrix.org>

15:27:51

then you have to grab the images from n-1 and n

<@dustymabe:matrix.org>

15:27:57

and then do your own inspection between the two

<@dustymabe:matrix.org>

15:28:09

it'd be easier if all of that was browsable

<@snthrailkill:matrix.org>

15:29:06

Hmm. Maybe a label thats ISO-8601 compliant to say when it was published? Then we make a tool that knows what tag to look for between 2 images and periodically checks a tag you specify for a given regisry

<@dustymabe:matrix.org>

15:29:09

so you could browse to a build that say "had the version XYZ-A of systemd" and copy the pullspec and test against it

<@dustymabe:matrix.org>

15:29:42

all of this is doable today.. I just want to make it easier

<@dustymabe:matrix.org>

15:30:05

mostly because I'm spoiled (see https://builds.coreos.fedoraproject.org/browser?stream=stable&arch=x86_64)

<@dustymabe:matrix.org>

15:31:07

also, with this build history accessible we can do things like [bisect](https://github.com/coreos/fedora-coreos-config/blob/d0b035279041708b169fdf274ece64dc399ed0ef/tests/manual/coreos-builds-bisect.py#L58-L61) the history to find out when a regression occurred

<@jbrooks:matrix.org>

15:31:30

Yeah, that's cool

<@snthrailkill:matrix.org>

15:32:40

I like how Dusty said it would be a small topic 😅

<@dustymabe:matrix.org>

15:33:27

Sean Thrailkill: I was surprised by the level of interest, but I think that's a good thing :)

<@jbrooks:matrix.org>

15:33:59

OK, other topics?

<@dustymabe:matrix.org>

15:34:17

Jason Brooks: so what are the takeaways from this discussion? should we try to summarize and put something in the ticket?

<@jbrooks:matrix.org>

15:34:46

Yeah, I think we should do that -- I was thinking, for me, I need to digest

<@jbrooks:matrix.org>

15:35:14

Would anyone like to summarize and add to the ticket? If not, I'll do it 🙂

<@snthrailkill:matrix.org>

15:35:35

I'll do it

<@jbrooks:matrix.org>

15:35:42

Sweet

<@jbrooks:matrix.org>

15:36:04

!action Sean Thrailkill to summarize our chat and add to Dusty's ticket

<@jbrooks:matrix.org>

15:37:16

the zodbot lag is killing me

<@jbrooks:matrix.org>

15:37:35

Do we have any other topics, or should we close this one off?

<@dustymabe:matrix.org>

15:38:11

I've got an open floor item

<@jeckersb:fedora.im>

15:38:27

yeah i have one small note too

<@jbrooks:matrix.org>

15:39:11

!topic open floor

<@jbrooks:matrix.org>

15:39:20

go ahead, Dusty

<@dustymabe:matrix.org>

15:40:24

and that URL can be found from https://calendar.fedoraproject.org/SIGs/#m10982

<@dustymabe:matrix.org>

15:40:24

<@dustymabe:matrix.org>

15:40:24

The URL is `https://calendar.fedoraproject.org/ical/calendar/meeting/10982/`

<@dustymabe:matrix.org>

15:40:24

<@dustymabe:matrix.org>

15:40:24

If anyone else uses google calendar (like I do). You can add this meetings cal entry to it by URL

<@dustymabe:matrix.org>

15:40:40

just a little nugget for anyone who might find that useful

<@dustymabe:matrix.org>

15:41:14

oh also I did a little hobby time this past weekend and got Fedora CoreOS building for riscv64

<@dustymabe:matrix.org>

15:41:32

which included some necessary changes to the bootc base images manifests.

<@dustymabe:matrix.org>

15:41:32

<@dustymabe:matrix.org>

15:41:32

I'll PR those later today

<@snthrailkill:matrix.org>

15:42:38

Very cool

<@jbrooks:matrix.org>

15:44:18

Awesome, we might have riscv hw at the Fedora booth at RH Summit, it'd be cool to run bootc on it

<@jbrooks:matrix.org>

15:45:25

Any other open floor items?

<@jbrooks:matrix.org>

15:46:00

OK, I'm closing it off, thanks everyone!

<@jeckersb:fedora.im>

15:46:03

Just a quick note, as of ~1hr ago we have updated `latest`/`42` fedora-bootc images - https://quay.io/repository/fedora/fedora-bootc?tab=history

<@jbrooks:matrix.org>

15:46:04

!endmeeting