2026-03-25 15:29:45 <@ydesouza:fedora.im> !startmeeting fedora_coreos_meeting
2026-03-25 15:29:46 <@meetbot:fedora.im> Meeting started at 2026-03-25 15:29:45 UTC
2026-03-25 15:29:47 <@meetbot:fedora.im> The Meeting name is 'fedora_coreos_meeting'
2026-03-25 15:30:06 <@ydesouza:fedora.im> !topic roll call
2026-03-25 15:30:47 <@nemric:relativit.fr> !hi
2026-03-25 15:30:49 <@zodbot:fedora.im> Emeric Chassagne (nemric)
2026-03-25 15:30:59 <@ravanelli:matrix.org> !hi ravanelli
2026-03-25 15:30:59 <@hricky:fedora.im> !hi
2026-03-25 15:31:00 <@zodbot:fedora.im> Hristo Marinov (hricky) - he / him / his
2026-03-25 15:31:21 <@zodbot:fedora.im> Renata Ravanelli (ravanelli)
2026-03-25 15:31:40 <@jcapitao:matrix.org> !hi o/
2026-03-25 15:31:42 <@zodbot:fedora.im> Sorry, but Fedora Accounts user 'o/' does not exist
2026-03-25 15:31:47 <@marmijo:fedora.im> !hi
2026-03-25 15:31:47 <@zodbot:fedora.im> Michael Armijo (marmijo)
2026-03-25 15:31:54 <@spresti:fedora.im> !hi
2026-03-25 15:31:56 <@osama-albahrani:matrix.org> !hi
2026-03-25 15:31:57 <@zodbot:fedora.im> Steven Presti (spresti)
2026-03-25 15:32:01 <@zodbot:fedora.im> Osama Albahrani (osalbahr)
2026-03-25 15:32:22 <@ydesouza:fedora.im> !topic Action items from last meeting
2026-03-25 15:32:29 <@zodbot:fedora.im> osalbahr gave a cookie to zodbot. They now have 43 cookies, 8 of which were obtained in the Fedora 43 release cycle
2026-03-25 15:32:38 <@rapneset:matrix.org> !hi
2026-03-25 15:32:41 <@ydesouza:fedora.im> * marmijo to involve jmarrero in https://github.com/coreos/rpm-ostree/issues/5539 to get an opinion on how to proceed
2026-03-25 15:32:41 <@zodbot:fedora.im> Rolv Apneseth (rapneset)
2026-03-25 15:32:44 <@siosm:matrix.org> !hi
2026-03-25 15:32:48 <@zodbot:fedora.im> Timothée Ravier (siosm) - he / him / his
2026-03-25 15:32:56 <@siosm:matrix.org> 👋
2026-03-25 15:33:15 <@ydesouza:fedora.im> Hello everyone!
2026-03-25 15:33:23 <@angelcr:matrix.org> !hi
2026-03-25 15:33:28 <@zodbot:fedora.im> Angel Cervera Roldan (acervera)
2026-03-25 15:33:32 <@ydesouza:fedora.im> Hey marmijo, any updates on this action item? :)
2026-03-25 15:34:36 <@zodbot:fedora.im> acervera gave a cookie to zodbot. They now have 44 cookies, 9 of which were obtained in the Fedora 43 release cycle
2026-03-25 15:35:05 <@marmijo:fedora.im> I sent jmarrero a private message and he said he would look at it when he has some time
2026-03-25 15:35:21 <@ydesouza:fedora.im> Thanks for working on this!
2026-03-25 15:35:38 <@ydesouza:fedora.im> So let's discuss our topics :)
2026-03-25 15:35:47 <@ydesouza:fedora.im> !topic Review Fedora 44 Release Schedule
2026-03-25 15:35:47 <@ydesouza:fedora.im> !link https://fedorapeople.org/groups/schedule/f-44/f-44-key-tasks.html
2026-03-25 15:36:58 <@dustymabe:matrix.org> !hi 
2026-03-25 15:37:07 <@ydesouza:fedora.im> So we are currently in our FCOS Test Week! Please. feel free to join us! Every contribution is important.
2026-03-25 15:37:11 <@zodbot:fedora.im> Dusty Mabe (dustymabe) - he / him / his
2026-03-25 15:37:43 <@ydesouza:fedora.im> And we have the Final Freeze happening March, 31 :)
2026-03-25 15:37:56 <@ydesouza:fedora.im> Next Tuesday
2026-03-25 15:38:33 <@ydesouza:fedora.im> I think that's it about the fedora release schedule :)
2026-03-25 15:39:22 <@ydesouza:fedora.im> Anyone has anything to add about this topic? 
2026-03-25 15:39:45 <@jbtrystram:matrix.org> !hi
2026-03-25 15:39:48 <@zodbot:fedora.im> Jean-Baptiste Trystram (jbtrystram) - he / him / his
2026-03-25 15:40:14 <@siosm:matrix.org> I see some things not checked in https://github.com/coreos/fedora-coreos-tracker/issues/2055
2026-03-25 15:40:17 <@siosm:matrix.org> for branching
2026-03-25 15:40:30 <@siosm:matrix.org> and beta
2026-03-25 15:40:42 <@siosm:matrix.org> (I don't know if they did happen)
2026-03-25 15:43:02 <@marmijo:fedora.im> Some of them did, some didn't. I need to revisit the steps regarding untagging old packages. Everything else has been completed AFAIK
2026-03-25 15:43:58 <@ydesouza:fedora.im> Thanks!
2026-03-25 15:44:16 <@ydesouza:fedora.im> Let's check our tracker repository
2026-03-25 15:44:23 <@ydesouza:fedora.im> !link https://github.com/coreos/fedora-coreos-tracker/issues/2126
2026-03-25 15:44:23 <@ydesouza:fedora.im> !topic Use afterburn to generate NetworkManager connection profile configurations (keyfiles)
2026-03-25 15:44:36 <@jlebon:fedora.im> !hi
2026-03-25 15:44:38 <@zodbot:fedora.im> None (jlebon)
2026-03-25 15:45:58 <@rapneset:matrix.org> Yeah this one is from me. Basically want to know how we would feel about adding NetworkManager keyfile generation into afterburn.
2026-03-25 15:49:07 <@rapneset:matrix.org> 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
2026-03-25 15:51:14 <@siosm:matrix.org> 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
2026-03-25 15:51:22 <@siosm:matrix.org> ah, kubevirt
2026-03-25 15:51:36 <@siosm:matrix.org> and vmware
2026-03-25 15:52:07 <@siosm:matrix.org> How / where would afterburn write those files? This may "conflicts" with Ignition's job as that's usually what we expect to write configuration.
2026-03-25 15:53:35 <@dustymabe:matrix.org> we generate systemd-networkd files ? 
2026-03-25 15:53:35 <@dustymabe:matrix.org> 
2026-03-25 15:53:35 <@dustymabe:matrix.org> > since we already do it for systemd-networkd unit files
2026-03-25 15:54:07 <@rapneset:matrix.org> 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
2026-03-25 15:54:21 <@rapneset:matrix.org> Yes we generate systemd-networkd files
2026-03-25 15:54:47 <@rapneset:matrix.org> Also netplan configurations
2026-03-25 15:54:59 <@siosm:matrix.org> https://github.com/coreos/afterburn/blob/main/docs/development/distro.md?plain=1#L21
2026-03-25 15:55:16 <@siosm:matrix.org> https://coreos.github.io/afterburn/development/distro/#vmware-netplan-guestinfo-metadata
2026-03-25 15:56:06 <@jlebon:fedora.im> 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.
2026-03-25 15:57:11 <@dustymabe:matrix.org> This topic seems to have strong overlap with https://github.com/coreos/fedora-coreos-tracker/issues/111
2026-03-25 15:57:11 <@dustymabe:matrix.org> 
2026-03-25 15:57:11 <@dustymabe:matrix.org> > 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.
2026-03-25 15:57:11 <@jlebon:fedora.im> 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
2026-03-25 15:57:43 <@dustymabe:matrix.org> at one point we were pursuing `nm-cloud-setup` 
2026-03-25 15:58:29 <@jlebon:fedora.im> what's funny though is that afterburn writes kargs, which are in turn already converted to NM keyfiles via the nm-initrd-generator.
2026-03-25 15:59:24 <@siosm:matrix.org> From a quick look, it feels like we are implementing writing NM keyfiles in Afterburn: https://github.com/coreos/afterburn/pull/1267
2026-03-25 15:59:30 <@rapneset:matrix.org> 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:
2026-03-25 15:59:30 <@rapneset:matrix.org> https://github.com/coreos/afterburn/pull/1266
2026-03-25 15:59:30 <@rapneset:matrix.org> 
2026-03-25 15:59:48 <@siosm:matrix.org> It's not that much code however so would be ok
2026-03-25 16:00:51 <@siosm:matrix.org> 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
2026-03-25 16:00:53 <@jlebon:fedora.im> 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.
2026-03-25 16:01:14 <@dustymabe:matrix.org> What problem did we hit with using kernel arguments? 
2026-03-25 16:01:14 <@dustymabe:matrix.org> > what's funny though is that afterburn writes kargs, which are in turn already converted to NM keyfiles via the nm-initrd-generator.
2026-03-25 16:01:14 <@dustymabe:matrix.org> That's a good point.
2026-03-25 16:01:14 <@dustymabe:matrix.org> 
2026-03-25 16:01:14 <@dustymabe:matrix.org> 
2026-03-25 16:01:49 <@jlebon:fedora.im> AIUI, not knowing what kargs to write because we don't have networking to ask the platform :)
2026-03-25 16:02:46 <@rapneset:matrix.org> I can't get the kernel arguments before networking is up because Hetzner only provides the data from an HTTP endpoint
2026-03-25 16:03:37 <@dustymabe:matrix.org> i'm confused though. Are we conflating two problems? 
2026-03-25 16:03:44 <@jlebon:fedora.im> rapneset: do you have reference docs on the Hetzner networking setup?
2026-03-25 16:04:21 <@rapneset:matrix.org> It could very well be I don't understand the problem enough, yes. What's the two problems?
2026-03-25 16:04:42 <@dustymabe:matrix.org> Is that correct? 
2026-03-25 16:04:42 <@dustymabe:matrix.org> problem 1. - we need some basic form of network up before we can retrieve metadata from an http endpoint
2026-03-25 16:04:42 <@dustymabe:matrix.org> 
2026-03-25 16:05:48 <@rapneset:matrix.org> 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: 
2026-03-25 16:05:48 <@rapneset:matrix.org> 
2026-03-25 16:05:48 <@rapneset:matrix.org> https://github.com/coreos/afterburn/issues/1141
2026-03-25 16:05:59 <@rapneset:matrix.org> Yes
2026-03-25 16:06:51 <@aaradhak:matrix.org> !hi aaradhak
2026-03-25 16:06:54 <@zodbot:fedora.im> Aashish Radhakrishnan (aaradhak)
2026-03-25 16:07:40 <@dustymabe:matrix.org> 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
2026-03-25 16:07:40 <@dustymabe:matrix.org> 
2026-03-25 16:09:14 <@rapneset:matrix.org> For Hetzner at least, the default config is sufficient
2026-03-25 16:09:35 <@jlebon:fedora.im> AIUI, for ipv6 DHCP is not sufficient, you need to reach out over link-local
2026-03-25 16:09:44 <@dustymabe:matrix.org> ok so `problem 1.` isn't really a problem? we can retrieve the metadata with just our default config (DHCP) ? 
2026-03-25 16:10:14 <@dustymabe:matrix.org> Jonathan Lebon: is the metadata service only available behind IPv6? 
2026-03-25 16:10:15 <@jlebon:fedora.im> yeah, i think that's the ipv4 vs ipv6 gap.
2026-03-25 16:10:49 <@rapneset:matrix.org> No, it's actually only available over IPv4 as far as I can tell
2026-03-25 16:11:25 <@rapneset:matrix.org> 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
2026-03-25 16:11:55 <@dustymabe:matrix.org> 
2026-03-25 16:11:55 <@dustymabe:matrix.org> ok so agree or not:
2026-03-25 16:11:55 <@dustymabe:matrix.org> `problem 1.` (accessing metadata) isn't a problem ? 
2026-03-25 16:12:07 <@spresti:fedora.im> Hmm, is that true? I know with openstack we would need to configure networking for both metatdata services to be available. 
2026-03-25 16:12:29 <@spresti:fedora.im> There were two endpoints but the vm would need to be on both interfaces.
2026-03-25 16:12:54 <@spresti:fedora.im> If we had a fully ipv6 stack would we still be able to reach ipv4 on hetzner?
2026-03-25 16:13:05 <@rapneset:matrix.org> 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
2026-03-25 16:13:27 <@dustymabe:matrix.org> yeah, I really don't understand rapneset :) 
2026-03-25 16:13:31 <@jlebon:fedora.im> yeah, that's exactly my question
2026-03-25 16:13:54 <@rapneset:matrix.org> I have provisioned a machine with only public IPv6 with these changes, yes
2026-03-25 16:14:13 <@rapneset:matrix.org> It has IPv4 locally as far as I understand
2026-03-25 16:15:06 <@siosm:matrix.org> It probably has local IPv4 but no public global IPv4
2026-03-25 16:15:14 <@jlebon:fedora.im> 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
2026-03-25 16:15:48 <@siosm:matrix.org> Note that we are almost out of time and it feems like this needs further research and clarification
2026-03-25 16:16:29 <@dustymabe:matrix.org> 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
2026-03-25 16:18:21 <@rapneset:matrix.org> 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
2026-03-25 16:18:40 <@rapneset:matrix.org> Hope that makes more sense, but I'm happy to table it for a side discussion
2026-03-25 16:19:04 <@dustymabe:matrix.org> rapneset: let's continue in the main channel after the meeting 
2026-03-25 16:19:21 <@rapneset:matrix.org> Sure, thanks everyone
2026-03-25 16:19:26 <@jlebon:fedora.im> rapneset: yup makes sense, so we want some kind of two stage enablement
2026-03-25 16:19:26 <@jlebon:fedora.im> yeah, let's table
2026-03-25 16:20:49 <@ydesouza:fedora.im> Should we go to the next topic
2026-03-25 16:21:05 <@ydesouza:fedora.im> !link https://github.com/coreos/fedora-coreos-tracker/issues/1465
2026-03-25 16:21:05 <@ydesouza:fedora.im> !topic increase size of our /boot partition for new installs
2026-03-25 16:21:21 <@dustymabe:matrix.org> ok I added this one.
2026-03-25 16:21:35 <@dustymabe:matrix.org> we don't have a lot of time here. I don't know if we need a lot of time necessarily today.
2026-03-25 16:21:35 <@dustymabe:matrix.org> 
2026-03-25 16:22:18 <@dustymabe:matrix.org> ahh. I see the comment I added recently was replied to 
2026-03-25 16:22:18 <@siosm:matrix.org> 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
2026-03-25 16:22:38 <@dustymabe:matrix.org> I thought the full `bootc` binary was getting added
2026-03-25 16:22:45 <@dustymabe:matrix.org> I thought the full `bootc` binary was getting added to the initramfs
2026-03-25 16:23:06 <@siosm:matrix.org> it's a smaller one for support for the composefs native backend
2026-03-25 16:23:23 <@siosm:matrix.org> we could even skip it for now, but we'll "soon" need it
2026-03-25 16:23:46 <@dustymabe:matrix.org> but Timothée Ravier (travier) - I do feel like we do need to come back to this problem
2026-03-25 16:23:46 <@dustymabe:matrix.org> 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 
2026-03-25 16:23:46 <@dustymabe:matrix.org> 
2026-03-25 16:25:17 <@siosm:matrix.org> 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
2026-03-25 16:25:24 <@siosm:matrix.org> 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
2026-03-25 16:26:05 <@siosm:matrix.org> (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)
2026-03-25 16:28:20 <@siosm:matrix.org> Can someone work on https://github.com/coreos/ignition/issues/2045 in the short term?
2026-03-25 16:29:38 <@dustymabe:matrix.org> so the solution to that issue is for us to not use the SDK/library ? 
2026-03-25 16:30:02 <@dustymabe:matrix.org> is that straightforward ? 
2026-03-25 16:30:04 <@siosm:matrix.org> I think so I'm afraid. IIRC it's only a few HTTP requests
2026-03-25 16:30:32 <@siosm:matrix.org> or figure out a proper way to not bundle everything in the binary, some sort of LTO for Go
2026-03-25 16:30:37 <@siosm:matrix.org> I don't know if that exists
2026-03-25 16:30:56 <@siosm:matrix.org> I'm pretty sure 99% of the Azure SDK is of no use to us
2026-03-25 16:31:29 <@ydesouza:fedora.im> Hey folks, we are finishing this meeting. Should I keep the label in this issue so we can continue to discuss next week?
2026-03-25 16:32:32 <@ydesouza:fedora.im> 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.
2026-03-25 16:32:41 <@siosm:matrix.org> I think so
2026-03-25 16:32:52 <@dustymabe:matrix.org> +1 
2026-03-25 16:32:59 <@dustymabe:matrix.org> thanks for the discussion all!
2026-03-25 16:33:22 <@ydesouza:fedora.im> Also, don't forget about our FCOS 44 Test Week! Feel free to participate!
2026-03-25 16:33:30 <@ydesouza:fedora.im> Thank you all for the meeting!
2026-03-25 16:33:48 <@ydesouza:fedora.im> !endmeeting