#meeting-1:fedoraproject.org log

<@ydesouza:fedora.im>

15:29:45

!startmeeting fedora_coreos_meeting

<@meetbot:fedora.im>

15:29:46

Meeting started at 2026-03-25 15:29:45 UTC

<@meetbot:fedora.im>

15:29:47

The Meeting name is 'fedora_coreos_meeting'

<@ydesouza:fedora.im>

15:30:06

!topic roll call

<@nemric:relativit.fr>

15:30:47

!hi

<@zodbot:fedora.im>

15:30:49

Emeric Chassagne (nemric)

<@ravanelli:matrix.org>

15:30:59

!hi ravanelli

<@hricky:fedora.im>

15:30:59

!hi

<@zodbot:fedora.im>

15:31:00

Hristo Marinov (hricky) - he / him / his

<@zodbot:fedora.im>

15:31:21

Renata Ravanelli (ravanelli)

<@jcapitao:matrix.org>

15:31:40

!hi o/

<@zodbot:fedora.im>

15:31:42

Sorry, but Fedora Accounts user 'o/' does not exist

<@marmijo:fedora.im>

15:31:47

!hi

<@zodbot:fedora.im>

15:31:47

Michael Armijo (marmijo)

<@spresti:fedora.im>

15:31:54

!hi

<@osama-albahrani:matrix.org>

15:31:56

!hi

<@zodbot:fedora.im>

15:31:57

Steven Presti (spresti)

<@zodbot:fedora.im>

15:32:01

Osama Albahrani (osalbahr)

<@ydesouza:fedora.im>

15:32:22

!topic Action items from last meeting

<@zodbot:fedora.im>

15:32:29

osalbahr gave a cookie to zodbot. They now have 43 cookies, 8 of which were obtained in the Fedora 43 release cycle

<@rapneset:matrix.org>

15:32:38

!hi

<@ydesouza:fedora.im>

15:32:41

* marmijo to involve jmarrero in https://github.com/coreos/rpm-ostree/issues/5539 to get an opinion on how to proceed

<@zodbot:fedora.im>

15:32:41

Rolv Apneseth (rapneset)

<@siosm:matrix.org>

15:32:44

!hi

<@zodbot:fedora.im>

15:32:48

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

<@siosm:matrix.org>

15:32:56

👋

<@ydesouza:fedora.im>

15:33:15

Hello everyone!

<@angelcr:matrix.org>

15:33:23

!hi

<@zodbot:fedora.im>

15:33:28

Angel Cervera Roldan (acervera)

<@ydesouza:fedora.im>

15:33:32

Hey marmijo, any updates on this action item? :)

<@zodbot:fedora.im>

15:34:36

acervera gave a cookie to zodbot. They now have 44 cookies, 9 of which were obtained in the Fedora 43 release cycle

<@marmijo:fedora.im>

15:35:05

I sent jmarrero a private message and he said he would look at it when he has some time

<@ydesouza:fedora.im>

15:35:21

Thanks for working on this!

<@ydesouza:fedora.im>

15:35:38

So let's discuss our topics :)

<@ydesouza:fedora.im>

15:35:47

!topic Review Fedora 44 Release Schedule

<@ydesouza:fedora.im>

15:35:47

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

<@dustymabe:matrix.org>

15:36:58

!hi

<@ydesouza:fedora.im>

15:37:07

So we are currently in our FCOS Test Week! Please. feel free to join us! Every contribution is important.

<@zodbot:fedora.im>

15:37:11

Dusty Mabe (dustymabe) - he / him / his

<@ydesouza:fedora.im>

15:37:43

And we have the Final Freeze happening March, 31 :)

<@ydesouza:fedora.im>

15:37:56

Next Tuesday

<@ydesouza:fedora.im>

15:38:33

I think that's it about the fedora release schedule :)

<@ydesouza:fedora.im>

15:39:22

Anyone has anything to add about this topic?

<@jbtrystram:matrix.org>

15:39:45

!hi

<@zodbot:fedora.im>

15:39:48

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

<@siosm:matrix.org>

15:40:14

I see some things not checked in https://github.com/coreos/fedora-coreos-tracker/issues/2055

<@siosm:matrix.org>

15:40:17

for branching

<@siosm:matrix.org>

15:40:30

and beta

<@siosm:matrix.org>

15:40:42

(I don't know if they did happen)

<@marmijo:fedora.im>

15:43:02

Some of them did, some didn't. I need to revisit the steps regarding untagging old packages. Everything else has been completed AFAIK

<@ydesouza:fedora.im>

15:43:58

Thanks!

<@ydesouza:fedora.im>

15:44:16

Let's check our tracker repository

<@ydesouza:fedora.im>

15:44:23

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

<@ydesouza:fedora.im>

15:44:23

!topic Use afterburn to generate NetworkManager connection profile configurations (keyfiles)

<@jlebon:fedora.im>

15:44:36

!hi

<@zodbot:fedora.im>

15:44:38

None (jlebon)

<@rapneset:matrix.org>

15:45:58

Yeah this one is from me. Basically want to know how we would feel about adding NetworkManager keyfile generation into afterburn.

<@rapneset:matrix.org>

15:49:07

Ran into an issue with the kargs approach we're using to setup NetworkManager in FCOS when trying to configure Hetzner (also made a PR for network configuration for that one to afterburn), because the only way to get the metadata is to make an HTTP request to their endpoint, meaning you need to fallback to the auto networking setup first before further configuration. I think it kind of makes sense to support generating the configurations for NetworkManager directly since we already do it for `systemd-networkd` unit files but wanted to hear from the community

<@siosm:matrix.org>

15:51:14

I see this looks like something we do for Proxmox? I don't see any other platforms in https://coreos.github.io/afterburn/platforms/ where we mention networking

<@siosm:matrix.org>

15:51:22

ah, kubevirt

<@siosm:matrix.org>

15:51:36

and vmware

<@siosm:matrix.org>

15:52:07

How / where would afterburn write those files? This may "conflicts" with Ignition's job as that's usually what we expect to write configuration.

<@dustymabe:matrix.org>

15:53:35

we generate systemd-networkd files ?

<@dustymabe:matrix.org>

15:53:35

<@dustymabe:matrix.org>

15:53:35

> since we already do it for systemd-networkd unit files

<@rapneset:matrix.org>

15:54:07

The way that Flatcar uses this is a service file which calls afterburn manually, as far as I understand it. In the draft PR I showed how I used it at least: https://github.com/coreos/afterburn/pull/1267

<@rapneset:matrix.org>

15:54:21

Yes we generate systemd-networkd files

<@rapneset:matrix.org>

15:54:47

Also netplan configurations

<@siosm:matrix.org>

15:54:59

https://github.com/coreos/afterburn/blob/main/docs/development/distro.md?plain=1#L21

<@siosm:matrix.org>

15:55:16

https://coreos.github.io/afterburn/development/distro/#vmware-netplan-guestinfo-metadata

<@jlebon:fedora.im>

15:56:06

I think Benjamin in the past has suggested that 'netplan' could be the common language and it knows how to convert to NM or systemd-networkd.

<@dustymabe:matrix.org>

15:57:11

This topic seems to have strong overlap with https://github.com/coreos/fedora-coreos-tracker/issues/111

<@dustymabe:matrix.org>

15:57:11

<@dustymabe:matrix.org>

15:57:11

> DigitalOcean does not provide DHCP for official images (no cloud agents: digitalocean #71 (comment)), network configuration is provided by an HTTP service on a link-local address.

<@jlebon:fedora.im>

15:57:11

i'm not sure if "it knows" means afterburn just importing the relevant crates/code, or if it'd require actually adding netplan to FCOS

<@dustymabe:matrix.org>

15:57:43

at one point we were pursuing `nm-cloud-setup`

<@jlebon:fedora.im>

15:58:29

what's funny though is that afterburn writes kargs, which are in turn already converted to NM keyfiles via the nm-initrd-generator.

<@siosm:matrix.org>

15:59:24

From a quick look, it feels like we are implementing writing NM keyfiles in Afterburn: https://github.com/coreos/afterburn/pull/1267

<@rapneset:matrix.org>

15:59:30

In the Hetzner network config PR, I did show using netplan, but not sure that's ideal if we don't already have it available on the system:

<@rapneset:matrix.org>

15:59:30

https://github.com/coreos/afterburn/pull/1266

<@rapneset:matrix.org>

15:59:30

<@siosm:matrix.org>

15:59:48

It's not that much code however so would be ok

<@siosm:matrix.org>

16:00:51

Yes, from memory when I looked at it on Ubuntu it's essentially a command that converts netplan files to NM or systemd-networkd on demand

<@jlebon:fedora.im>

16:00:53

Yeah, agree. The idea of a common interface sounds nice, but I think the end result is that it just further complicates our networking story.

<@dustymabe:matrix.org>

16:01:14

What problem did we hit with using kernel arguments?

<@dustymabe:matrix.org>

16:01:14

> what's funny though is that afterburn writes kargs, which are in turn already converted to NM keyfiles via the nm-initrd-generator.

<@dustymabe:matrix.org>

16:01:14

That's a good point.

<@dustymabe:matrix.org>

16:01:14

<@dustymabe:matrix.org>

16:01:14

<@jlebon:fedora.im>

16:01:49

AIUI, not knowing what kargs to write because we don't have networking to ask the platform :)

<@rapneset:matrix.org>

16:02:46

I can't get the kernel arguments before networking is up because Hetzner only provides the data from an HTTP endpoint

<@dustymabe:matrix.org>

16:03:37

i'm confused though. Are we conflating two problems?

<@jlebon:fedora.im>

16:03:44

rapneset: do you have reference docs on the Hetzner networking setup?

<@rapneset:matrix.org>

16:04:21

It could very well be I don't understand the problem enough, yes. What's the two problems?

<@dustymabe:matrix.org>

16:04:42

Is that correct?

<@dustymabe:matrix.org>

16:04:42

problem 1. - we need some basic form of network up before we can retrieve metadata from an http endpoint

<@dustymabe:matrix.org>

16:04:42

<@rapneset:matrix.org>

16:05:48

To be honest I couldn't find good documentation on it, and was relying on other people's examples I found online, including the original issue that inspired all this:

<@rapneset:matrix.org>

16:05:48

<@rapneset:matrix.org>

16:05:48

https://github.com/coreos/afterburn/issues/1141

<@rapneset:matrix.org>

16:05:59

Yes

<@aaradhak:matrix.org>

16:06:51

!hi aaradhak

<@zodbot:fedora.im>

16:06:54

Aashish Radhakrishnan (aaradhak)

<@dustymabe:matrix.org>

16:07:40

ok. so for `problem 1.` we need either our default config (DHCP) to be sufficient, or we need to bake in some platform defaults that will get us to network env that's good enough to retrieve the metadata

<@dustymabe:matrix.org>

16:07:40

<@rapneset:matrix.org>

16:09:14

For Hetzner at least, the default config is sufficient

<@jlebon:fedora.im>

16:09:35

AIUI, for ipv6 DHCP is not sufficient, you need to reach out over link-local

<@dustymabe:matrix.org>

16:09:44

ok so `problem 1.` isn't really a problem? we can retrieve the metadata with just our default config (DHCP) ?

<@dustymabe:matrix.org>

16:10:14

Jonathan Lebon: is the metadata service only available behind IPv6?

<@jlebon:fedora.im>

16:10:15

yeah, i think that's the ipv4 vs ipv6 gap.

<@rapneset:matrix.org>

16:10:49

No, it's actually only available over IPv4 as far as I can tell

<@rapneset:matrix.org>

16:11:25

But we make the request for networking metadata over IPv4 locally, even on machines that only have a public IPv6, and then setup IPv6 networking

<@dustymabe:matrix.org>

16:11:55

<@dustymabe:matrix.org>

16:11:55

ok so agree or not:

<@dustymabe:matrix.org>

16:11:55

`problem 1.` (accessing metadata) isn't a problem ?

<@spresti:fedora.im>

16:12:07

Hmm, is that true? I know with openstack we would need to configure networking for both metatdata services to be available.

<@spresti:fedora.im>

16:12:29

There were two endpoints but the vm would need to be on both interfaces.

<@spresti:fedora.im>

16:12:54

If we had a fully ipv6 stack would we still be able to reach ipv4 on hetzner?

<@rapneset:matrix.org>

16:13:05

It is not a problem _after_ when the kargs would be helpful to know, if that makes sense? Not sure if there is some miscommunication on my end

<@dustymabe:matrix.org>

16:13:27

yeah, I really don't understand rapneset :)

<@jlebon:fedora.im>

16:13:31

yeah, that's exactly my question

<@rapneset:matrix.org>

16:13:54

I have provisioned a machine with only public IPv6 with these changes, yes

<@rapneset:matrix.org>

16:14:13

It has IPv4 locally as far as I understand

<@siosm:matrix.org>

16:15:06

It probably has local IPv4 but no public global IPv4

<@jlebon:fedora.im>

16:15:14

ok so there is no "IPv6 only" provisioning where you don't have IPv4 at all then? that would point to problem 1 indeed not being an issue

<@siosm:matrix.org>

16:15:48

Note that we are almost out of time and it feems like this needs further research and clarification

<@dustymabe:matrix.org>

16:16:29

We can try to dig in deeper here, or we can table it for a side discussion and come back to it later if we want to discuss other things

<@rapneset:matrix.org>

16:18:21

It's correct that our DHCP fallback works fine to fetch the network configuration - the issue is this is only setup after we would need to know the kargs, am I correct in saying that? Hence why I went on the tangent of creating the network manager configuration files, since at the point afterburn is queried for the kargs, there is no default networking setup

<@rapneset:matrix.org>

16:18:40

Hope that makes more sense, but I'm happy to table it for a side discussion

<@dustymabe:matrix.org>

16:19:04

rapneset: let's continue in the main channel after the meeting

<@rapneset:matrix.org>

16:19:21

Sure, thanks everyone

<@jlebon:fedora.im>

16:19:26

rapneset: yup makes sense, so we want some kind of two stage enablement

<@jlebon:fedora.im>

16:19:26

yeah, let's table

<@ydesouza:fedora.im>

16:20:49

Should we go to the next topic

<@ydesouza:fedora.im>

16:21:05

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

<@ydesouza:fedora.im>

16:21:05

!topic increase size of our /boot partition for new installs

<@dustymabe:matrix.org>

16:21:21

ok I added this one.

<@dustymabe:matrix.org>

16:21:35

we don't have a lot of time here. I don't know if we need a lot of time necessarily today.

<@dustymabe:matrix.org>

16:21:35

<@dustymabe:matrix.org>

16:22:18

ahh. I see the comment I added recently was replied to

<@siosm:matrix.org>

16:22:18

I commented in https://github.com/coreos/fedora-coreos-tracker/issues/1465#issuecomment-4127616252 for this one. I think we should prioritize reducing the Ignition binary size and in parallel start the more long term work

<@dustymabe:matrix.org>

16:22:38

I thought the full `bootc` binary was getting added

<@dustymabe:matrix.org>

16:22:45

I thought the full `bootc` binary was getting added to the initramfs

<@siosm:matrix.org>

16:23:06

it's a smaller one for support for the composefs native backend

<@siosm:matrix.org>

16:23:23

we could even skip it for now, but we'll "soon" need it

<@dustymabe:matrix.org>

16:23:46

but Timothée Ravier (travier) - I do feel like we do need to come back to this problem

<@dustymabe:matrix.org>

16:23:46

and also consider the UKI stuff and the entire architecture to see if we can come up with something that makes supporting that easier too

<@dustymabe:matrix.org>

16:23:46

<@siosm:matrix.org>

16:25:17

yes, we'll have to have a discussion on the on-disk format so that we can support both BIOS, UEFI & UKI setups with a single image

<@siosm:matrix.org>

16:25:24

yes, we'll need to have a discussion on the on-disk format so that we can support both BIOS, UEFI & UKI setups with a single image

<@siosm:matrix.org>

16:26:05

(and if we want to drop support for BIOS at some point or make it 'not the default', i.e. needing some re-provisioning on first boot)

<@siosm:matrix.org>

16:28:20

Can someone work on https://github.com/coreos/ignition/issues/2045 in the short term?

<@dustymabe:matrix.org>

16:29:38

so the solution to that issue is for us to not use the SDK/library ?

<@dustymabe:matrix.org>

16:30:02

is that straightforward ?

<@siosm:matrix.org>

16:30:04

I think so I'm afraid. IIRC it's only a few HTTP requests

<@siosm:matrix.org>

16:30:32

or figure out a proper way to not bundle everything in the binary, some sort of LTO for Go

<@siosm:matrix.org>

16:30:37

I don't know if that exists

<@siosm:matrix.org>

16:30:56

I'm pretty sure 99% of the Azure SDK is of no use to us

<@ydesouza:fedora.im>

16:31:29

Hey folks, we are finishing this meeting. Should I keep the label in this issue so we can continue to discuss next week?

<@ydesouza:fedora.im>

16:32:32

We will not have time for a Open Floor discussion today but feel free to reach out in the matrix channel if there is any topic to discuss.

<@siosm:matrix.org>

16:32:41

I think so

<@dustymabe:matrix.org>

16:32:52

<@dustymabe:matrix.org>

16:32:59

thanks for the discussion all!

<@ydesouza:fedora.im>

16:33:22

Also, don't forget about our FCOS 44 Test Week! Feel free to participate!

<@ydesouza:fedora.im>

16:33:30

Thank you all for the meeting!

<@ydesouza:fedora.im>

16:33:48

!endmeeting