<@siosm:matrix.org>
15:30:45
!startmeeting fedora_coreos_meeting
<@meetbot:fedora.im>
15:30:49
Meeting started at 2025-12-17 15:30:45 UTC
<@meetbot:fedora.im>
15:30:49
The Meeting name is 'fedora_coreos_meeting'
<@siosm:matrix.org>
15:30:57
!topic roll call
<@siosm:matrix.org>
15:31:27
!hi
<@zodbot:fedora.im>
15:31:30
Timothée Ravier (siosm) - he / him / his
<@marmijo:fedora.im>
15:31:37
!hi
<@zodbot:fedora.im>
15:31:39
Michael Armijo (marmijo)
<@hricky:fedora.im>
15:32:00
!hi
<@zodbot:fedora.im>
15:32:02
Hristo Marinov (hricky) - he / him / his
<@ravanelli:matrix.org>
15:32:20
!hi ravanelli
<@zodbot:fedora.im>
15:32:26
Renata Ravanelli (ravanelli)
<@dustymabe:matrix.org>
15:34:10
!hi
<@zodbot:fedora.im>
15:34:12
Dusty Mabe (dustymabe) - he / him / his
<@siosm:matrix.org>
15:36:46
Let's start
<@siosm:matrix.org>
15:36:48
!topic Action items from last meeting
<@ydesouza:fedora.im>
15:36:51
!hi
<@zodbot:fedora.im>
15:36:53
Yasmin Valim de Souza (ydesouza)
<@siosm:matrix.org>
15:36:54
!link https://discussion.fedoraproject.org/t/fedora-coreos-community-meeting-minutes-2025-12-10/176623
<@siosm:matrix.org>
15:36:59
I don't see anything there.
<@siosm:matrix.org>
15:37:52
!topic Review Fedora 44 Release Schedule
<@jbtrystram:matrix.org>
15:37:53
!hi
<@siosm:matrix.org>
15:37:56
!link https://fedorapeople.org/groups/schedule/f-44/f-44-key-tasks.html
<@zodbot:fedora.im>
15:37:56
Jean-Baptiste Trystram (jbtrystram) - he / him / his
<@siosm:matrix.org>
15:38:15
We are at "Change Checkpoint: Proposal submission deadline (Changes requiring infrastructure changes)"
<@siosm:matrix.org>
15:39:02
Reminder that folks should submit their change requests before the system wide deadline 2025-12-23 or self contained 2026-01-13
<@siosm:matrix.org>
15:40:39
I have https://fedoraproject.org/wiki/Changes/SudoRsDefault in my backlog if folks are interested in working on this one
<@siosm:matrix.org>
15:40:47
(not yet submitted)
<@dustymabe:matrix.org>
15:41:25
I wonder if we should try to do something about the /boot partition size for F44
<@dustymabe:matrix.org>
15:41:25
https://github.com/coreos/fedora-coreos-tracker/issues/1465
<@dustymabe:matrix.org>
15:41:25
<@marmijo:fedora.im>
15:42:41
The rebase checklist now has steps to complete at the first change checkpoint. https://github.com/coreos/fedora-coreos-tracker/issues/2055. I'll be untagging old packages from the pool today.
<@siosm:matrix.org>
15:42:42
yeah that would be good
<@siosm:matrix.org>
15:42:52
lots of things behind it however
<@dustymabe:matrix.org>
15:43:56
marmijo: nice. let me know if you want me to sit in on that.
<@dustymabe:matrix.org>
15:44:15
Timothée Ravier (travier): yeah. it depends on if we want to actually change the strategy - or just the size
<@marmijo:fedora.im>
15:44:25
Sounds good. We did it together last cycle too!
<@siosm:matrix.org>
15:45:10
if we drop the requirement to support re-provisionning or preserving partitions then we can probably simply the scope
<@jbtrystram:matrix.org>
15:45:27
Wdym by strategy ?
<@dustymabe:matrix.org>
15:46:40
jbtrystram: i.e. number of partitions we have - how bootloaders get chained
<@dustymabe:matrix.org>
15:46:51
sorry I'm derailing. Continue!
<@siosm:matrix.org>
15:48:01
That's a good issue to move to the top of the priority list indeed
<@siosm:matrix.org>
15:48:51
I've updated the labels, let's move on
<@siosm:matrix.org>
15:49:02
!topic KubeVirt support for ignition with annotations
<@siosm:matrix.org>
15:49:05
!link https://github.com/coreos/fedora-coreos-tracker/issues/2081
<@siosm:matrix.org>
15:49:32
Do we have kubevirt folks here today? Or should we postpone that to January and invite them?
<@dustymabe:matrix.org>
15:50:00
Either way. I asked Alice to open this issue.
<@siosm:matrix.org>
15:50:05
Alice Frosi can you chime in?
<@dustymabe:matrix.org>
15:51:08
basically when we first developed kubevirt support for FCOS (Ignition) this option to use the qemu-fw interface in Kubevirt itself didn't exist (IIUC)
<@dustymabe:matrix.org>
15:51:51
now we have two ways that ignition could be provided to a kubevirt instance
<@dustymabe:matrix.org>
15:51:56
I'm not sure what we should do.
<@dustymabe:matrix.org>
15:52:02
the old way works well
<@siosm:matrix.org>
15:52:05
we had two related changes there recently: https://github.com/coreos/ignition/commits/main/internal/providers/kubevirt/kubevirt.go
<@jcapitao:matrix.org>
15:52:20
!hi
<@zodbot:fedora.im>
15:52:35
Joel Capitao (jcapitao) - he / him / his
<@siosm:matrix.org>
15:52:47
I vaguely remember the qemu fwconfig way being slower but more reliable than config disks
<@siosm:matrix.org>
15:53:12
but if the config disks are not going away and we already have that working, not sure what the benefit would be to change / add another way
<@dustymabe:matrix.org>
15:53:54
I can think of some negatives and positives
<@dustymabe:matrix.org>
15:54:23
the only negative I can see with keeping our current strategy is that someone reads kubevirt docs (not our docs) and tries with the Ignition way and it doesn't work.
<@dustymabe:matrix.org>
15:55:11
the negative I see with trying to support more ways is added complexity. and also the qemu-fw is known to not work on all architectures (if kubevirt ever expands)
<@siosm:matrix.org>
15:55:50
I think we can make a PR to update / remove the kubevirt docs
<@dustymabe:matrix.org>
15:56:05
like the upstream kubevirt docs?
<@siosm:matrix.org>
15:56:25
yes
<@dustymabe:matrix.org>
15:56:53
I don't know if that's the right move.
<@dustymabe:matrix.org>
15:57:12
basically qemu-fw does work, but our Ignition provider for kubevirt doesn't use it.
<@dustymabe:matrix.org>
15:57:35
so if you use a disk with `ignition.platform=qemu` it would work
<@dustymabe:matrix.org>
15:57:50
but not a disk with `ignition.platform=kubevirt`
<@siosm:matrix.org>
15:58:34
https://github.com/kubevirt/kubevirt.github.io/pull/167
<@siosm:matrix.org>
15:59:27
https://github.com/kubevirt/kubevirt/pull/1657
<@siosm:matrix.org>
15:59:44
I think we should talk to them in an issue
<@dustymabe:matrix.org>
15:59:52
hmm. that was a while ago
<@dustymabe:matrix.org>
16:00:20
+1 - but what should we say?
<@siosm:matrix.org>
16:01:29
https://github.com/kubevirt/kubevirt/pull/9862
<@siosm:matrix.org>
16:02:02
Looks like a general "what's the status of things and what can we drop / update" discussion would be good
<@dustymabe:matrix.org>
16:02:37
+1 sounds good to me
<@siosm:matrix.org>
16:03:17
what we are using right now is generic so it's not going away: https://kubevirt.io/user-guide/storage/disks_and_volumes/#cloudinitconfigdrive
<@siosm:matrix.org>
16:04:12
OK, I'll file an issue upstream
<@zodbot:fedora.im>
16:04:33
dustymabe gave a cookie to siosm. They now have 47 cookies, 4 of which were obtained in the Fedora 43 release cycle
<@siosm:matrix.org>
16:05:38
!topic tracker: Fedora 44 changes considerations
<@siosm:matrix.org>
16:05:42
!link https://github.com/coreos/fedora-coreos-tracker/issues/2063
<@siosm:matrix.org>
16:06:04
Let's go over the remaining changes, not sure if things have been updated since last week
<@marmijo:fedora.im>
16:07:06
Yes, there are only two changes to review today: https://github.com/coreos/fedora-coreos-tracker/issues/2063#issuecomment-3662389191
<@siosm:matrix.org>
16:07:20
104. Protobuf 5.x/6.x
<@siosm:matrix.org>
16:07:31
!link https://fedoraproject.org/wiki/Changes/Protobuf_5.x/6.x
<@siosm:matrix.org>
16:08:01
general dependency update, should be fine, I don't think we directly use that
<@marmijo:fedora.im>
16:08:39
I think spresti mentioned that we vendor protobuf in our upstream packages
<@siosm:matrix.org>
16:09:16
https://github.com/coreos/ignition/blob/049bed4f53d67392dfe4934cc46352e2032ba495/go.mod#L99
<@siosm:matrix.org>
16:09:37
https://pkg.go.dev/google.golang.org/protobuf
<@siosm:matrix.org>
16:09:53
Look like a pure go module so should not be impacted
<@siosm:matrix.org>
16:10:49
116: Use kmscon as default VT console
<@siosm:matrix.org>
16:11:00
!link https://fedoraproject.org/wiki/Changes/UseKmsconVTConsole
<@siosm:matrix.org>
16:11:12
This one is interesting and will likely have an impact for us
<@siosm:matrix.org>
16:11:49
it should not touch the serial console however so maybe this will be transparent
<@siosm:matrix.org>
16:13:10
so this will likely be added via comps to other Fedora editions so we'll have to "mirror" change in our config
<@conan_kudo:matrix.org>
16:13:39
I would say you should be aware that this is a precursor to disabling the VTs entirely in the kernel
<@siosm:matrix.org>
16:14:39
yep
<@siosm:matrix.org>
16:15:18
I think we mostly rely on serial console anyway so this is for the remaining cases where people have a graphical interface
<@dustymabe:matrix.org>
16:15:41
just so I'm clear.. `disabling the VTs entirely in the kernel` -> there would still be one term available on say tty0 ? you just wouldn't be able to switch via key combination to a diffeerent one?
<@siosm:matrix.org>
16:15:56
Conan KudoI don't see a comps PR. Do you know how this will be enabled?
<@dustymabe:matrix.org>
16:15:58
just so I'm clear.. `disabling the VTs entirely in the kernel` -> there would still be one term available on say tty0 ? you just wouldn't be able to switch via key combination to a different one?
<@siosm:matrix.org>
16:16:14
Conan KudoI don't see a comps PR. Do you know how will this be enabled?
<@conan_kudo:matrix.org>
16:16:17
not yet
<@conan_kudo:matrix.org>
16:16:28
there would be nothing
<@conan_kudo:matrix.org>
16:16:37
you need the userspace services to have ptys
<@conan_kudo:matrix.org>
16:16:51
no in-kernel VT means everything is delegated to userspace
<@siosm:matrix.org>
16:17:49
there should probably be a few releases before we turn that off
<@siosm:matrix.org>
16:18:23
OK, so we'll need an issue to track that. I'll make one
<@siosm:matrix.org>
16:20:30
anything else?
<@marmijo:fedora.im>
16:21:16
Nothin else from me on this topic, those were the only two change to review
<@marmijo:fedora.im>
16:21:22
Nothing else from me on this topic, those were the only two change to review
<@siosm:matrix.org>
16:21:44
!topic Open Floor
<@ravanelli:matrix.org>
16:22:30
this is probably the last meeting in the year?
<@siosm:matrix.org>
16:22:43
Ah yes!
<@siosm:matrix.org>
16:22:52
Should we cancel the next two meetings?
<@ravanelli:matrix.org>
16:23:05
+1
<@marmijo:fedora.im>
16:23:18
+1
<@dustymabe:matrix.org>
16:23:23
+1
<@ydesouza:fedora.im>
16:23:47
+1
<@siosm:matrix.org>
16:24:17
+1
<@siosm:matrix.org>
16:24:46
Dusty: can you do something for the reminder or the calendar events?
<@siosm:matrix.org>
16:25:08
or nothing if it's too painful
<@dustymabe:matrix.org>
16:25:25
I'm not sure. I can try. but I don't know if I mess with it if it will throw off the future ones or not
<@dustymabe:matrix.org>
16:25:48
the interface to fedocal is definitely lacking in a lot of ways
<@marmijo:fedora.im>
16:26:31
I can at least send out an email/discussion post
<@siosm:matrix.org>
16:27:01
sending an email/post should be good
<@siosm:matrix.org>
16:27:14
I agree that fedocal is a bit weird sometimes
<@dustymabe:matrix.org>
16:27:56
yep. I deleted them and it deleted all the future ones :)
<@dustymabe:matrix.org>
16:28:09
even though the check box for delete all future wasn't checked
<@marmijo:fedora.im>
16:29:12
so we'll resume meetings on 2026-01-07?
<@dustymabe:matrix.org>
16:29:14
oh well. I'll try to create it again in the new year
<@siosm:matrix.org>
16:30:13
yeah, fedocal...
<@marmijo:fedora.im>
16:30:15
!info This is the last FCOS meeting of the year due to the end-of-year holidays. We'll resume meetings on 2026-01-07. Happy holidays from the CoreOS team!
<@siosm:matrix.org>
16:30:48
Closing in 1 min of nothing comes up
<@siosm:matrix.org>
16:33:42
!endmeeting