#meeting-1:fedoraproject.org log

<@nimbinatus:matrix.org>

14:59:49

!startmeeting Fedora Image Mode Initiative

<@meetbot:fedora.im>

14:59:52

Meeting started at 2025-10-28 14:59:49 UTC

<@meetbot:fedora.im>

14:59:53

The Meeting name is 'Fedora Image Mode Initiative'

<@nimbinatus:matrix.org>

14:59:57

!topic roll call

<@nimbinatus:matrix.org>

15:00:02

!hi

<@zodbot:fedora.im>

15:00:05

Laura Santamaria (nimbinatus) - she / her / hers

<@snthrailkill:matrix.org>

15:00:10

!hi

<@zodbot:fedora.im>

15:00:15

Sean Thrailkill (snthrailkill)

<@rsturla:fedora.im>

15:00:59

!hi

<@zodbot:fedora.im>

15:01:02

None (rsturla)

<@jharmison:fedora.im>

15:01:12

!hi

<@zodbot:fedora.im>

15:01:14

None (jharmison)

<@hricky:fedora.im>

15:01:16

!hi

<@zodbot:fedora.im>

15:01:17

Hristo Marinov (hricky) - he / him / his

<@walters:fedora.im>

15:01:26

!hi

<@zodbot:fedora.im>

15:01:29

Colin Walters (walters)

<@nimbinatus:matrix.org>

15:03:35

(I'll wait until 5 past for people to finish filtering in)

<@jmarrero:matrix.org>

15:04:03

!hi

<@zodbot:fedora.im>

15:04:20

Joseph Marrero (jmarrero)

<@misc:ephaone.org>

15:06:15

!hi

<@zodbot:fedora.im>

15:06:17

No Fedora Accounts users have the @misc:ephaone.org Matrix Account defined

<@nimbinatus:matrix.org>

15:07:01

ok, time for topics to begin :)

<@nimbinatus:matrix.org>

15:07:38

!topic the effort to get image mode related bugs in the release blocking process

<@nimbinatus:matrix.org>

15:07:51

so I'll be honest that I don't know much about how this works

<@hricky:fedora.im>

15:08:11

The only image mode edition that is currently release blocking is Fedora IoT and it was almost dropped at such for the already passed F43 release cycle. As far as I know, the Fedora QE team has limited, at least human, resources at the moment and no one is dedicated to testing image based systems.

<@walters:fedora.im>

15:08:28

do you have a link for this one?

<@nimbinatus:matrix.org>

15:09:00

For the specific release blocker noted, or the general topic?

<@jharmison:fedora.im>

15:11:52

This was a recent bug that was rejected as a release blocker because it didn't affect package mode F43, to serve as an example of the effect of the problem. The authselect bug would affect anything bootc or ostree based.

<@jharmison:fedora.im>

15:11:52

<@jharmison:fedora.im>

15:11:52

!link https://pagure.io/fedora-qa/blocker-review/issue/1936

<@walters:fedora.im>

15:11:52

This came up last time, I think we're definitely way overdue to push on the testing side in Fedora in an automated fashion, https://gitlab.com/fedora/bootc/tracker/-/issues/18 has some links on this. It's a bit nebulous to me who "owns" this but I think we can spend some bandwidth on it

<@nimbinatus:matrix.org>

15:12:48

<@nimbinatus:matrix.org>

15:12:48

As we move forward on the march to F44 and F45, who owns posting things like this?

<@nimbinatus:matrix.org>

15:12:48

There are other issues that I've come across that seem to be blockers in my mind, but I don't know if blockers need champions in this project overall, or if they just need to get added to a specific tracker, or...

<@nimbinatus:matrix.org>

15:14:05

I really need to go through all of those issues on the tracker and map out where we are and what's next 🤦‍♀️

<@nimbinatus:matrix.org>

15:16:50

Regarding that blocker review link, it does sound like we need to get priority on things like Silverblue or other bootc artifacts as release blocking?

<@nimbinatus:matrix.org>

15:17:03

(which I guess is part of this work, since we need to establish production)

<@jharmison:fedora.im>

15:17:43

I think, generally, if we say bootc issues are release blocking we would want to use one or more atomic desktops as well as CoreOS as sort of realized effects of those bugs.

<@jharmison:fedora.im>

15:18:00

E.g. not just requiring the bootc minimal/standard base to complete an upgrade, but reference implementations of bootc-based images.

<@jharmison:fedora.im>

15:19:24

Getting that agreed upon seems like a challenge as long as the QE gap remains

<@walters:fedora.im>

15:19:33

We have multiple CI signals, I think it's mostly a wiring process but how some of that works is not clear to me. I'd say to me the dist-git gating is a lot more important than the blocker process as it creates a natural forcing function

<@hricky:fedora.im>

15:23:00

FCOS is practically invisible to QE, it's not a release blocking edition, but it's pretty well tested, as far as I know.

<@snthrailkill:matrix.org>

15:25:37

Isn't that because they do they're testing outside of the usual channels?

<@snthrailkill:matrix.org>

15:25:50

Isn't that because they do their testing outside of the usual channels?

<@walters:fedora.im>

15:26:26

yes

<@walters:fedora.im>

15:27:01

This one has lingered for a really really long time in a status quo, definitely time to shake some things up more. I think we can centralize on https://gitlab.com/fedora/bootc/tracker/-/issues/1 as the issue here

<@dustymabe:matrix.org>

15:27:17

ehh. basically if bugs are blockers the CoreOS team makes sure they get proposed as blocker bugs https://qa.fedoraproject.org/blockerbugs/milestone/44/final/buglist

<@jharmison:fedora.im>

15:28:10

With the current status quo being that those bugs are free to get rejected if they don't affect package mode

<@nimbinatus:matrix.org>

15:29:32

it sounds like I need to get someone from QE in the initiative here so that we can establish how to ensure the bugs aren't rejected?

<@nimbinatus:matrix.org>

15:29:48

(as we figure out the gating and CI needs to help push those forward)

<@walters:fedora.im>

15:30:47

I guess we can ask Jonathan Lebon how he wired up to bodhi, we definitely have the tooling to do something similar

<@dustymabe:matrix.org>

15:31:51

Colin Walters: most of the logic is in https://github.com/coreos/coreos-ci/tree/main/jobs

<@dustymabe:matrix.org>

15:32:20

the bodhi-trigger job listens for fedora messages from bodhi and then triggers the test-override job

<@dustymabe:matrix.org>

15:32:34

the bodhi-trigger job listens for fedora messages from bodhi and then triggers the test-override job, which reports back results

<@dustymabe:matrix.org>

15:32:48

results also get posted to https://matrix.to/#/#jenkins-coreos:fedoraproject.org

<@walters:fedora.im>

15:36:07

will this stuff get migrated to konflux?

<@dustymabe:matrix.org>

15:36:40

no idea, we're early in our konflux migration. will start with container image builds first

<@nimbinatus:matrix.org>

15:44:10

- First up is focusing on !link https://gitlab.com/fedora/bootc/tracker/-/issues/1 as a work item. Sounds like a good action is updating that ticket, making sure everything is linked (including !link https://gitlab.com/fedora/bootc/tracker/-/issues/18 ?), and then...

<@nimbinatus:matrix.org>

15:44:10

So sounds like we've got a couple things here:

<@nimbinatus:matrix.org>

15:44:10

- Start mapping logic like found at !link https://github.com/coreos/coreos-ci/tree/main/jobs to a Konflux pipeline, and hooking in any other wiring that needs to get done from the CI work we already have.

<@nimbinatus:matrix.org>

15:44:27

(now, can meetbot handle multiple commands in a comment...)

<@nimbinatus:matrix.org>

15:45:01

Does that sound like good takeaways here to y'all?

<@walters:fedora.im>

15:46:28

yeah

<@walters:fedora.im>

15:47:01

in a nutshell it's complex since there's like 7 different CI/build/integration systems going on and subets of people work on subsets of those

<@nimbinatus:matrix.org>

15:47:12

Yup, kinda figured

<@walters:fedora.im>

15:47:21

(for example, only 1/3 of Fedora derivatives use bodhi)

<@nimbinatus:matrix.org>

15:48:51

But we do still want to standardize for this initiative (base images, pipeline system, etc.) on Konflux, ya?

<@walters:fedora.im>

15:49:33

Yeah though that only changes part of the subsets

<@nimbinatus:matrix.org>

15:49:34

I know Jenkinsfiles very well (scripted pipeline is what I used to use all the time), and I bet mapping to the Konflux flavor of YAML isn't too bad

<@rsturla:fedora.im>

15:49:38

I'm currently in the early stages of helping out Atomic Desktops to move as much as possible over to Konflux

<@nimbinatus:matrix.org>

15:50:28

Re subsets, yeah, but I want to be sure we know what our target is so we don't flounder trying to pick one 😂

<@snthrailkill:matrix.org>

15:51:27

As much as I'd love to build this stuff somewhere easier with more tooling and stuff, Id hate to make things more opaque and convoluted. So I think moving to the standard tool (Konflux) is where we should be

<@walters:fedora.im>

15:56:08

right, though currently for example some of the tests we run use tmt/testing-farm which predates konflux - we have wired up the two

<@walters:fedora.im>

15:56:27

but that's it's own big subtopic

<@nimbinatus:matrix.org>

15:59:37

all right, I do want to let this conversation keep going, but we're also almost at time. We can move to the bootc channel to keep talking about this. However, let me summarize some stuff for the notes here in a moment (after Colin's done typing :D )

<@nimbinatus:matrix.org>

16:00:13

!action Update and add all links to https://gitlab.com/fedora/bootc/tracker/-/issues/1 so we can pick that up ASAP.

<@nimbinatus:matrix.org>

16:00:34

!action Start mapping logic like found at https://github.com/coreos/coreos-ci/tree/main/jobs to a Konflux pipeline, and hooking in any other wiring that needs to get done from the CI work we already have.

<@nimbinatus:matrix.org>

16:01:04

!agreed we're going to stick with Konflux for the pipeline for this initiative

<@nimbinatus:matrix.org>

16:01:57

And on that, I think I've gotten everything down for the summary. Y'all have a great rest of your week, and happy spooky season week for those of you who are in areas of the world that celebrate :)

<@nimbinatus:matrix.org>

16:02:08

!endmeeting