#meeting-1:fedoraproject.org log

<@siosm:matrix.org>

15:30:29

!startmeeting fedora_coreos_meeting

<@meetbot:fedora.im>

15:30:32

Meeting started at 2026-01-14 15:30:29 UTC

<@meetbot:fedora.im>

15:30:32

The Meeting name is 'fedora_coreos_meeting'

<@siosm:matrix.org>

15:30:38

!topic roll call

<@marmijo:fedora.im>

15:31:25

!hi

<@zodbot:fedora.im>

15:31:26

Michael Armijo (marmijo)

<@spresti:fedora.im>

15:32:23

!hi

<@zodbot:fedora.im>

15:32:25

Steven Presti (spresti)

<@siosm:matrix.org>

15:32:57

!hi

<@zodbot:fedora.im>

15:33:00

Timothée Ravier (siosm) - he / him / his

<@jbtrystram:matrix.org>

15:33:42

!hi

<@zodbot:fedora.im>

15:33:44

Jean-Baptiste Trystram (jbtrystram) - he / him / his

<@siosm:matrix.org>

15:35:10

!topic Action items from last meeting

<@siosm:matrix.org>

15:35:16

!link https://discussion.fedoraproject.org/t/fedora-coreos-community-meeting-minutes-2026-01-07/179133

<@siosm:matrix.org>

15:35:25

I don't see any action items

<@dustymabe:matrix.org>

15:35:57

<@dustymabe:matrix.org>

15:36:01

!hi

<@zodbot:fedora.im>

15:36:04

Dusty Mabe (dustymabe) - he / him / his

<@siosm:matrix.org>

15:36:28

!topic Review Fedora 44 Release Schedule

<@siosm:matrix.org>

15:36:41

!link https://fedorapeople.org/groups/schedule/f-44/f-44-key-tasks.html

<@siosm:matrix.org>

15:37:02

We've reached the Change Checkpoint: Proposal submission deadline (Self Contained Changes)

<@siosm:matrix.org>

15:37:12

so the churn around change should start to slow down

<@dustymabe:matrix.org>

15:37:41

ehh. that's just the submissions though.. when the work lands that's when we hit breakage usually (in rawhide)

<@siosm:matrix.org>

15:37:55

I think the mass rebuild is going to start soon so watch out for packages that we maintain that may fail to build

<@dustymabe:matrix.org>

15:38:06

also, the submissions only show up in our tracker issue when they've been accepted

<@siosm:matrix.org>

15:38:18

yep, changes can still be accepted and implemented until the Change Checkpoint: 100% Code Complete Deadline Tue 2026-02-17

<@siosm:matrix.org>

15:40:40

Does anyone want to bring up a specific topic? Otherwise we'll go to open floor

<@jbtrystram:matrix.org>

15:41:10

looks like the konflux change did not get picked up by wrangler : https://fedoraproject.org/wiki/Changes/Build_FCOS_on_Fedora_Konflux ?

<@jbtrystram:matrix.org>

15:41:34

I probably messed something. Is that bad ? does it means we have to push this to f45 ?

<@siosm:matrix.org>

15:43:11

it's not in the right category

<@siosm:matrix.org>

15:43:29

i.e. you did not submit it

<@hricky:fedora.im>

15:43:32

!hi

<@zodbot:fedora.im>

15:43:34

Hristo Marinov (hricky) - he / him / his

<@dustymabe:matrix.org>

15:43:48

I think it's OK. we can plead ignorance and I'm sure we can get it considered

<@siosm:matrix.org>

15:44:46

I also think it's OK as it's just for FCOS. Can you fix the Wiki page and send a mail to Allison King? (the change wrangler)

<@siosm:matrix.org>

15:45:15

(with a note that we missed the deadline and we're sorry)

<@marmijo:fedora.im>

15:45:31

I didn't re-add the meeting label, but there are new changes that came through for Fedora 44. I don't think any of them affect FCOS, but i'd like a second pair of eyes on the new changes: https://github.com/coreos/fedora-coreos-tracker/issues/2063#issuecomment-3747111611

<@jbtrystram:matrix.org>

15:45:37

I just updated the change. yeah, that's entirely my bad

<@siosm:matrix.org>

15:46:03

!topic tracker: Fedora 44 changes considerations

<@siosm:matrix.org>

15:46:13

!link https://github.com/coreos/fedora-coreos-tracker/issues/2063

<@siosm:matrix.org>

15:46:33

Thanks marmijofor keeping this updated

<@zodbot:fedora.im>

15:46:47

siosm gave a cookie to marmijo. They now have 18 cookies, 1 of which were obtained in the Fedora 43 release cycle

<@marmijo:fedora.im>

15:47:12

You're welcome!

<@siosm:matrix.org>

15:47:22

So we should verify https://github.com/coreos/fedora-coreos-tracker/issues/2063#issuecomment-3716677516 & https://github.com/coreos/fedora-coreos-tracker/issues/2063#issuecomment-3747111611

<@siosm:matrix.org>

15:47:55

Everything looks good to me 👍

<@zodbot:fedora.im>

15:48:20

dustymabe gave a cookie to marmijo. They now have 19 cookies, 2 of which were obtained in the Fedora 43 release cycle

<@dustymabe:matrix.org>

15:48:26

Thank you marmijo

<@marmijo:fedora.im>

15:48:39

Great, thanks! The most recent list of changes we're tracking is here: https://github.com/coreos/fedora-coreos-tracker/issues/2063#issuecomment-3662389191

<@siosm:matrix.org>

15:50:40

https://github.com/coreos/fedora-coreos-tracker/issues/2086 is likely the item with the highest chance of regressions

<@siosm:matrix.org>

15:51:16

the comps PR just landed so we can mirror the change in f-c-c and see if our tests passes at least

<@siosm:matrix.org>

15:51:39

This should be a fairly small change. Is anyone intersted in working on this?

<@cverna_:matrix.org>

15:53:57

!hi

<@zodbot:fedora.im>

15:54:01

Clement Verna (cverna) - he / him / his

<@spresti:fedora.im>

15:54:08

Im down to grab it. I have not done that before but happy to learn

<@zodbot:fedora.im>

15:54:28

dustymabe gave a cookie to spresti. They now have 4 cookies, 1 of which were obtained in the Fedora 43 release cycle

<@zodbot:fedora.im>

15:54:33

marmijo gave a cookie to spresti. They now have 5 cookies, 2 of which were obtained in the Fedora 43 release cycle

<@siosm:matrix.org>

15:54:38

OK I've just installed the package in a VM and it has a good list of dependencies so maybe we should look at that first

<@zodbot:fedora.im>

15:54:47

siosm gave a cookie to spresti. They now have 6 cookies, 3 of which were obtained in the Fedora 43 release cycle

<@dustymabe:matrix.org>

15:55:22

Timothée Ravier (travier): we can look at it, but eventually the old version of this is getting ripped out of the kernel, right?

<@siosm:matrix.org>

15:55:31

yeah

<@siosm:matrix.org>

15:55:47

but maybe we can ask for some things to be turned to recommends

<@dustymabe:matrix.org>

15:55:55

I'm guessing these changes should go into the bootc base image manifests? and we inherit from there?

<@siosm:matrix.org>

15:56:00

for more server like steups

<@siosm:matrix.org>

15:56:06

oh indeed

<@siosm:matrix.org>

15:56:16

this should definitely go in bootc first

<@dustymabe:matrix.org>

15:56:37

yes, and we'll automatically pick them up

<@dustymabe:matrix.org>

15:57:26

i.e. when this gets bumped: https://github.com/coreos/fedora-coreos-config/blob/91190836ef3185c79cf66d401fb1e2984d4b9d7d/build-args.conf#L11

<@spresti:fedora.im>

15:59:29

++ okay I can look into adding the change to the bootc manifest then, thank you!

<@dustymabe:matrix.org>

16:01:57

open floor?

<@siosm:matrix.org>

16:03:03

yep

<@siosm:matrix.org>

16:03:09

!topic Open Floor

<@dustymabe:matrix.org>

16:03:23

!action spresti to look into kmscon change

<@dustymabe:matrix.org>

16:03:47

FYI flock details have been released

<@dustymabe:matrix.org>

16:03:54

https://fedoraproject.org/flock/2026/

<@dustymabe:matrix.org>

16:04:03

!link https://fedoraproject.org/flock/2026/

<@jbtrystram:matrix.org>

16:05:02

I plan to get to flock this year ! :)

<@siosm:matrix.org>

16:05:31

Deadline: February 02

<@siosm:matrix.org>

16:05:31

Flock Call for Proposals

<@spresti:fedora.im>

16:05:37

Ooooo thats exciting!

<@dustymabe:matrix.org>

16:05:41

Let's get a few talks submitted

<@peytonrobertson:matrix.org>

16:06:27

The Linux Provisioning Team did have a new proposal for Ignition we would like to discuss if you all have time with open floor!

<@siosm:matrix.org>

16:07:01

I think we have time. Let's make a topic

<@siosm:matrix.org>

16:07:25

!topic Proposal from the Provisioning Team related to Ignition

<@siosm:matrix.org>

16:07:29

go ahead!

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

https://github.com/coreos/ignition/pull/2185

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

We can commit to bringing Ignition to parity with cloud-init on Azure and maintaining Azure-specific features, but this would expand Ignition’s scope. Community feedback is needed on whether this is acceptable. The fallback is to replace WALinuxAgent PA with azure-init and address Ignition’s limitations separately.

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

This presents an opportunity to make Ignition a first-class provisioning agent on Azure, more closely aligned with cloud-init’s Azure datasource. Ignition’s ignition-fetch.service already overlaps with cloud-init’s local phase by mounting provisioning media and fetching instance metadata. The proposed --generate-cloud-config approach (see azure: add --generate-cloud-config for user ignition config generation by peytonr18 · Pull Request …) shows how cloud-specific behavior can be added by reusing Ignition’s existing configuration APIs as a clear, stable contract - similar to how Azure configuration is translated into cloud-init config. Afterburn does not address these gaps and is not well-suited as the contract surface for this functionality.

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

Azure-init can replace WALinuxAgent for tasks such as admin user creation, SSH key and password setup, and sshd configuration, but it does not address Ignition’s needs for accessing custom and user data.

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

The majority of Azure VMs currently use cloud-init for VM provisioning. WALinuxAgent provisioning is being deprecated in favor of azure-init, and we are evaluating how best to support Flatcar and Fedora CoreOS. Upcoming changes to Azure Confidential VMs will encrypt custom data and sign user data, which is expected to break Ignition and prevent its use in CVM scenarios. Additionally, enabling Azure’s Metadata Security Protocol (MSP) requires Ignition to change how it fetches user data from IMDS due to the azure-proxy-agent requirement.

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

Proposal for Expanding Ignition with Cloud-Specific Configuration

<@peytonrobertson:matrix.org>

16:08:27

<@peytonrobertson:matrix.org>

16:08:27

Thank you! Let me share a little blurb about it that was written by Chris and should help outline the proposal:

<@dustymabe:matrix.org>

16:11:44

There's a lot in there :)

<@siosm:matrix.org>

16:11:58

OK that's a lot to review during a meeting. Maybe filling an Ignition issue to discuss this would be a good start?

<@dustymabe:matrix.org>

16:12:05

Should we consider a dedicated session (maybe video community meeting) on this topic?

<@cjp256:matrix.org>

16:12:41

that would be great!

<@siosm:matrix.org>

16:13:08

This appears to be related to https://github.com/coreos/afterburn/issues/1242 ?

<@dustymabe:matrix.org>

16:13:31

next week or the following week same time work? spresti I think you have organized a video meeting before? would you be willing to organize this one?

<@peytonrobertson:matrix.org>

16:14:04

It is. That proposal, which I can close, was our original attempt at this but after hearing feedback from you all and speaking internally amongst our team and the Flatcar team, we decided to pivot to utilizing Ignition instead

<@siosm:matrix.org>

16:14:39

OK, feel free to close the afterburn issue and mention it in the new ignition one

<@spresti:fedora.im>

16:15:42

Sure, happy to organize a video meeting dustymabe. What week is preferred Peyton Robertson ?

<@peytonrobertson:matrix.org>

16:16:12

Next week would work great!

<@siosm:matrix.org>

16:16:25

> The --generate-cloud-config flag enables Ignition to dynamically synthesize an Ignition configuration from cloud provider metadata at boot time, rather than requiring a pre-baked Ignition config in user data.

<@siosm:matrix.org>

16:16:25

<@siosm:matrix.org>

16:16:25

However that sounds like it contradicts the design behind Ignition

<@dustymabe:matrix.org>

16:17:36

!action spresti to organize video community meeting for next week and send communication to the mailing list/forum about it.

<@dustymabe:matrix.org>

16:17:40

Thank you spresti !

<@siosm:matrix.org>

16:18:12

<@siosm:matrix.org>

16:18:12

However that sounds like it conflicts with the design behind Ignition

<@siosm:matrix.org>

16:18:12

<@spresti:fedora.im>

16:18:29

NP, I did want to quickly talk about butane to ignition merge as well as per last weeks conv

<@siosm:matrix.org>

16:19:12

Let's make a new topic then?

<@spresti:fedora.im>

16:19:22

Sure

<@siosm:matrix.org>

16:19:33

!topic Ignition & Butane merge

<@spresti:fedora.im>

16:21:12

Ok so I have been going through the process of actually merging butane into ignition. In doing that I made some assumptions that might need to be questioned.

<@spresti:fedora.im>

16:21:12

Firstly I used a git subtree. In theory this makes sense it preserves all refrences and helps us track down features.. in practice the PR is 1000+ commits pulled from butanes repo... do we care enough to maintain git history?

<@spresti:fedora.im>

16:21:12

<@siosm:matrix.org>

16:25:35

It would be nice if we could preserve the history. On first though I would have merged the two tree directly but maybe that does not work

<@spresti:fedora.im>

16:27:41

Hmm, what do you mean by directly?

<@spresti:fedora.im>

16:27:41

Yeah I would prefer to know why things exist and how they are associated to each tag

<@spresti:fedora.im>

16:27:41

<@spresti:fedora.im>

16:28:40

The other stumbles are expected, docs.. ci... packaging.. I have taken a first sweep at those, but I have a feeling its likely going to have got-ya due to the scope of the changes.

<@siosm:matrix.org>

16:28:44

i.e. move all butane code to a butane subdirectory, commit, then in the ignition repo add the butane repo as remote and do a git merge --unrelated-history

<@siosm:matrix.org>

16:29:16

and then a lot of cleanups to de-duplicate

<@spresti:fedora.im>

16:30:00

Ok, I can try that path.

<@spresti:fedora.im>

16:32:16

<@spresti:fedora.im>

16:32:16

I am still concerned that we are merging into a monolith repo, it feels wrong but I have nothing that tells me we cant do it, as there seems to be some benefits.

<@spresti:fedora.im>

16:32:16

We are at time, let me try that to see if its looks better.

<@siosm:matrix.org>

16:33:41

hopefully with the cleanups & de-duplication we should end up with less code overall

<@siosm:matrix.org>

16:34:07

and indeed, we are at time so if nothing else is urgent, I'll close this one

<@siosm:matrix.org>

16:36:43

!endmeeting