<@siosm:matrix.org>
16:30:23
!startmeeting fedora_coreos_meeting
<@meetbot:fedora.im>
16:30:26
Meeting started at 2024-11-20 16:30:23 UTC
<@meetbot:fedora.im>
16:30:26
The Meeting name is 'fedora_coreos_meeting'
<@siosm:matrix.org>
16:30:31
!topic roll call
<@siosm:matrix.org>
16:31:00
!hi
<@zodbot:fedora.im>
16:31:02
Timothรฉe Ravier (siosm) - he / him / his
<@gurssing:matrix.org>
16:31:03
!hi gursewak
<@zodbot:fedora.im>
16:31:06
Gursewak Singh (gursewak)
<@dustymabe:matrix.org>
16:31:10
!hi
<@zodbot:fedora.im>
16:31:12
Dusty Mabe (dustymabe) - he / him / his
<@marmijo:fedora.im>
16:31:28
!hi
<@zodbot:fedora.im>
16:31:29
Michael Armijo (marmijo)
<@hricky:fedora.im>
16:31:55
!hi
<@zodbot:fedora.im>
16:31:56
Hristo Marinov (hricky) - he / him / his
<@jlebon:fedora.im>
16:33:28
!hi
<@zodbot:fedora.im>
16:33:30
None (jlebon)
<@aaradhak:matrix.org>
16:35:14
!hi aaradhak
<@zodbot:fedora.im>
16:35:16
Aashish Radhakrishnan (aaradhak)
<@siosm:matrix.org>
16:36:09
!topic Action items from last meeting
<@apiaseck:matrix.org>
16:36:17
!hi
<@siosm:matrix.org>
16:36:18
<@zodbot:fedora.im>
16:36:19
Adam Piasecki (c4rt0) - he / him / his
<@siosm:matrix.org>
16:36:40
There are no action items from the previous meeting as far as I can see.
<@siosm:matrix.org>
16:37:09
Should we start with the F42 changes?
<@siosm:matrix.org>
16:37:47
!topic tracker: Fedora 42 changes considerations
<@siosm:matrix.org>
16:37:56
<@marmijo:fedora.im>
16:38:36
I updated the script to look at F42 changes and created this issue. I already did a preliminary pass and added some notes for changes that have been deferred from previous release cycles.
<@marmijo:fedora.im>
16:38:49
There are a few new change considerations to review though
<@siosm:matrix.org>
16:38:58
Thanks!
<@siosm:matrix.org>
16:39:04
Let's do a quick review of the remaining ones
<@siosm:matrix.org>
16:39:36
!info 101. Update Zlib-ng to version 2.2.x
<@siosm:matrix.org>
16:39:44
<@siosm:matrix.org>
16:40:41
We ship `zlib-ng-compat`. This should come as an update for us. Nothing specific to do.
<@siosm:matrix.org>
16:41:13
!info 106. Enable systemd service hardening features for default system services
<@siosm:matrix.org>
16:41:20
<@dustymabe:matrix.org>
16:41:28
> Considering that API and ABI are expected to be kept the same, no impacts are expected.
<@dustymabe:matrix.org>
16:41:52
I think nothing for us to do unless our tests start to fail
<@siosm:matrix.org>
16:42:01
agree
<@siosm:matrix.org>
16:42:27
For the systemd services hardening one, we already have a tracking issue for it. Nothing specific more to do.
<@siosm:matrix.org>
16:42:50
!info 107. Unify /usr/bin and /usr/sbin
<@siosm:matrix.org>
16:42:57
<@siosm:matrix.org>
16:43:34
I think Colin did the work for this one: https://gitlab.com/fedora/bootc/tracker/-/issues/29
<@siosm:matrix.org>
16:43:58
We will have to check Rawhide to confirm that this is OK.
<@jlebon:fedora.im>
16:44:07
doesn't seem like we got feedback yet whether it's sufficient
<@siosm:matrix.org>
16:44:10
Apart from that, I don't think there is anything else to do.
<@dustymabe:matrix.org>
16:44:26
hmm. what if users have already written stuff into `/usr/local/sbin/` on existing systems?
<@siosm:matrix.org>
16:44:56
I don't think that touches anything /usr/local related
<@siosm:matrix.org>
16:45:12
It's only /usr/bin /usr/sbin
<@siosm:matrix.org>
16:45:28
ah, my bad, it's not from the change page
<@jlebon:fedora.im>
16:45:51
`/usr/local` is node state currently, so it can't really touch that
<@dustymabe:matrix.org>
16:46:00
> The same change is also done to make /usr/local/sbin point to bin, effectively making /usr/local/bin/foo and /usr/local/sbin/foo point to the same place.
<@siosm:matrix.org>
16:46:04
Then we need some form of migration / transition / warning
<@dustymabe:matrix.org>
16:46:37
Jonathan Lebon: if they are going to drop `/usr/local/sbin` from the path then they'll need to migrate sbin to bin
<@dustymabe:matrix.org>
16:47:01
but really I feel like this is a global Fedora problem and not FCOS specific
<@jlebon:fedora.im>
16:47:35
hmm ok, yeah this needs some investigation for the upgrading case
<@dustymabe:matrix.org>
16:48:07
<@dustymabe:matrix.org>
16:48:07
doesn't say they are going to remove `/usr/local/sbin` from path
<@dustymabe:matrix.org>
16:48:07
<@dustymabe:matrix.org>
16:48:07
> /usr/sbin will be removed from the default $PATH
<@dustymabe:matrix.org>
16:48:07
though.. it only says:
<@siosm:matrix.org>
16:48:07
In Fedora the migration is done in a postprocess script that will not run for us
<@dustymabe:matrix.org>
16:48:20
so maybe we should just clarify that
<@jlebon:fedora.im>
16:49:24
travier: there might be a delta though between new vs upgrading nodes
<@siosm:matrix.org>
16:49:30
Alright,n I've marked https://github.com/coreos/fedora-coreos-tracker/issues/1759 as needing action/investigation
<@siosm:matrix.org>
16:50:00
Jonathan Lebon: Yes, we might need some migration
<@jlebon:fedora.im>
16:50:22
currently `/usr/local` is populated via tmpfiles shipped by rpm-ostree, and i don't think we changed anything there yet
<@jlebon:fedora.im>
16:50:49
https://github.com/coreos/rpm-ostree/blob/main/src/app/rpm-ostree-0-integration.conf#L8-L18
<@siosm:matrix.org>
16:50:58
I've just booted up a Rawhide FCOS and it's not in there so looks like this did not land yet
<@jlebon:fedora.im>
16:51:23
that'll require some tweaking on the rpm-ostree side too i think
<@siosm:matrix.org>
16:52:51
I asked in https://gitlab.com/fedora/bootc/tracker/-/issues/29 if there are any updates
<@siosm:matrix.org>
16:53:10
!info 112. Retire zbus v1
<@siosm:matrix.org>
16:53:17
<@siosm:matrix.org>
16:54:33
I think we should be good for this one
<@dustymabe:matrix.org>
16:54:46
doesn't look like we own any of the packages that are still using the old zbus v1?
<@siosm:matrix.org>
16:54:50
ah, no, we ship nmstate
<@dustymabe:matrix.org>
16:55:00
right, but we don't own that package?
<@siosm:matrix.org>
16:55:04
yep
<@siosm:matrix.org>
16:55:11
so we'll only need to watch it
<@siosm:matrix.org>
16:55:43
> No action for our packages. We will have to watch the progress for the nmstate package.
<@siosm:matrix.org>
16:56:00
!info 204. Confidential Virtualization Host with AMD SEV-SNP
<@siosm:matrix.org>
16:56:09
<@siosm:matrix.org>
16:57:06
It does not look like we have anything specific to do here for now
<@dustymabe:matrix.org>
16:58:06
travier: because we already added support for GCP?
<@dustymabe:matrix.org>
16:58:14
https://github.com/coreos/fedora-coreos-tracker/issues/1777#issuecomment-2328567389
<@jlebon:fedora.im>
16:58:28
might be good to add CI for it
<@siosm:matrix.org>
16:58:30
No, the support for GCP/Azure is for running as guest
<@siosm:matrix.org>
16:58:36
this is for running as a host
<@siosm:matrix.org>
16:58:53
we would need specific hardware to test that
<@siosm:matrix.org>
16:59:06
I don't think we can get that kind of hardware in the clouds AFAIK
<@dustymabe:matrix.org>
16:59:31
ok, so we'd need some bare metal hardware in Fedora infra to be able to test it? what are the change owners using?
<@jlebon:fedora.im>
17:00:30
but anyway, this is unlikely to have anything FCOS-specific. it looks more like enablement in the kernel and qemu
<@jlebon:fedora.im>
17:00:30
gcp supports nested virt but not sure if SEV-SNP nests.
<@dustymabe:matrix.org>
17:01:49
travier: can you clarify [Huijing's comment](https://github.com/coreos/fedora-coreos-tracker/issues/1777#issuecomment-2328567389) when you update the issue? She is specifically talking about guest, whereas this change is talking about host support
<@siosm:matrix.org>
17:02:44
Apparently we support sandboxed containers (which is similar but not the same) on some clouds so maybe this could work in some clouds https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.7/html/user_guide/index
<@siosm:matrix.org>
17:03:17
but yeah, this is not something specific to us apart form testing that it works but that's another problem
<@siosm:matrix.org>
17:04:07
!info 206. Enable Drm Panic
<@siosm:matrix.org>
17:04:13
<@siosm:matrix.org>
17:05:04
So be transparent (hopefully not or we would not see the QR code ๐Ÿ™ƒ) to us
<@siosm:matrix.org>
17:05:41
!info 207. Tomcat 10.1.x
<@siosm:matrix.org>
17:05:48
<@siosm:matrix.org>
17:05:53
We don't ship Tomcat.
<@dustymabe:matrix.org>
17:06:31
purple screen of death!
<@siosm:matrix.org>
17:06:39
!info 208. Integrate FEX in Fedora Linux
<@siosm:matrix.org>
17:06:44
<@jlebon:fedora.im>
17:07:34
i could imagine that one coming up in the tracker at some point
<@siosm:matrix.org>
17:07:48
We don't ship FEX. But if it's faster than QEMU on aarch64 to emulate x86-64 containers then that may be interesting
<@jlebon:fedora.im>
17:07:49
given that we ship qemu today for this purpose
<@siosm:matrix.org>
17:08:22
That would be a prime candidate for a sysexts (go hide behind a corner) ๐Ÿ™‚
<@siosm:matrix.org>
17:08:31
That would be a prime candidate for a sysext (go hide behind a corner) ๐Ÿ™‚
<@jlebon:fedora.im>
17:08:34
would be annoying to ship both though. i think this is probably more an argument for removing qemu :)
<@jlebon:fedora.im>
17:08:46
or layering, yeah
<@dustymabe:matrix.org>
17:08:47
is FEX better or something?
<@jlebon:fedora.im>
17:09:01
it's faster apparently
<@dustymabe:matrix.org>
17:09:21
> QEMU is the best implementation for correctness, but it's extremely slow in comparison, making it unsuitable for a lot of practical usecases (such as gaming).
<@siosm:matrix.org>
17:09:23
It is getting development and optimization effort from the Asahi crowd
<@dustymabe:matrix.org>
17:09:30
ehh. I'm more interested in correctness TBH
<@siosm:matrix.org>
17:09:53
agree, for server use cases we want correctness
<@jlebon:fedora.im>
17:10:34
i guess it depends if the "non-correctness" is well-understood and people know what's safe to run and what isn't
<@dustymabe:matrix.org>
17:11:14
I say let's no-op for now and revisit if requests come in
<@siosm:matrix.org>
17:11:24
yes
<@jlebon:fedora.im>
17:11:30
let's just skip the next one and go straight to 210
<@siosm:matrix.org>
17:12:06
209 PHP, we don't include it
<@siosm:matrix.org>
17:12:26
!info 210. Distributing Kickstart Files as OCI Artifacts
<@siosm:matrix.org>
17:12:34
<@siosm:matrix.org>
17:13:05
This does not impact us
<@dustymabe:matrix.org>
17:13:09
honestly I don't really get it
<@siosm:matrix.org>
17:13:18
We could do things related to that but it's not a requirement
<@siosm:matrix.org>
17:14:19
!info 209. PHP 8.4
<@siosm:matrix.org>
17:14:25
<@siosm:matrix.org>
17:14:32
We don't ship PHP (for the notes)
<@siosm:matrix.org>
17:14:44
!info 211. Enabling composefs by default for Atomic Desktops
<@siosm:matrix.org>
17:14:50
<@siosm:matrix.org>
17:15:00
This is for the Atomic Desktops and we already did this in FCOS.
<@siosm:matrix.org>
17:15:04
So nothing else to do
<@dustymabe:matrix.org>
17:15:12
๐ŸŽ‰
<@siosm:matrix.org>
17:15:18
Alright, we're at the end. Anything else?
<@dustymabe:matrix.org>
17:15:37
marmijo: how do you want to handle updates with results from this meeting?
<@siosm:matrix.org>
17:15:42
Which issue of the two other ones should we talk about in the 10 minutes remaining?
<@jlebon:fedora.im>
17:15:46
yeah, not sure either. i guess the idea is about making distribution easier. if tooling around this picks up, there could be asks to deliver our live artifacts via OCI as well. anyway, obviously something that's happening in parallel to just be aware of for now
<@marmijo:fedora.im>
17:16:33
dustymabe: I dont think there are any new trackers to open, so I'll update the tracker issue with the results.
<@marmijo:fedora.im>
17:16:42
dustymabe: I dont think there are any new trackers to open, so I'll update the changes tracker issue with the results.
<@jlebon:fedora.im>
17:17:24
i think basically it's about improving the ergonomics around finding live artifacts. but for FCOS, we did that with the stream metadata, which has public APIs and e.g. go/rust bindings etc...
<@dustymabe:matrix.org>
17:17:36
marmijo: thank you for picking this up and keeping things up to date over in https://pagure.io/fork/dustymabe/fedora-pgm/pgm_scripts/commits/dusty-fcos-changes
<@marmijo:fedora.im>
17:17:54
of course!
<@siosm:matrix.org>
17:18:25
Should we move that repo to the coreos org to make it more visible? (not urgent, can happen later)
<@dustymabe:matrix.org>
17:19:01
:) - you mean from pagure to github?
<@siosm:matrix.org>
17:19:02
Time is getting short so I'll move to open floor soon.
<@siosm:matrix.org>
17:19:11
yeah :)
<@dustymabe:matrix.org>
17:19:27
maybe.. it's kind of a fork of an unrelated repo, though
<@siosm:matrix.org>
17:19:57
alright, does not have to happen. We'll revisit that once pagure goes away (hopefully at some point)
<@siosm:matrix.org>
17:20:48
!topic Open Floor
<@siosm:matrix.org>
17:21:30
Thanks to everybody that did the F41 releases! Looks like a smooth update :) (We did not get a lot of issues from what I could see :) )
<@dustymabe:matrix.org>
17:22:53
Yep. went pretty smooth. I'd say the biggest problem was not booting on VMWare, but we fixed that in the beta cycle and it never shipped to `testing`/`stable`
<@jbtrystram:matrix.org>
17:22:53
Hey all ! Just chiming to say I have an eye on the dracut/kdump stuff that have been discussed recently and if it does not become urgent I will pick that up when I am back
<@dustymabe:matrix.org>
17:23:10
Thanks jbtrystram
<@jlebon:fedora.im>
17:23:27
jbtrystram: hope things are going well!
<@jbtrystram:matrix.org>
17:25:56
Jonathan Lebon thanks for asking :) not 100% smooth sailing but nothing too extraordinary
<@jbtrystram:matrix.org>
17:27:25
I wanted to attend community meetings but it's right at the time of day when we need all hands on deck. Not sure I'll be able to attend them for a while to be honest
<@dustymabe:matrix.org>
17:27:48
don't worry about it - go where needed :)
<@jbtrystram:matrix.org>
17:28:01
Thanks everyone for f41!
<@siosm:matrix.org>
17:29:28
baby dinner time! :)
<@siosm:matrix.org>
17:29:53
Alright, closing in 1 min :)
<@siosm:matrix.org>
17:32:12
!endmeeting