16:31:07 #startmeeting fedora_coreos_meeting 16:31:07 Meeting started Wed Mar 8 16:31:07 2023 UTC. 16:31:07 This meeting is logged and archived in a public location. 16:31:07 The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 16:31:07 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:31:07 The meeting name has been set to 'fedora_coreos_meeting' 16:31:16 #topic roll call 16:31:17 .hi 16:31:17 dustymabe: dustymabe 'Dusty Mabe' 16:31:38 hi 16:32:06 #chair PhrozenByte 16:32:06 Current chairs: PhrozenByte dustymabe 16:32:13 .hi 16:32:14 jdoss: jdoss 'Joe Doss' 16:32:22 oh hi 16:32:38 .hi 16:32:39 gursewak: gursewak 'Gursewak Singh' 16:32:41 .hello siosm 16:32:42 travier: siosm 'Timothée Ravier' 16:33:10 #chair jdoss gursewak travier 16:33:10 Current chairs: PhrozenByte dustymabe gursewak jdoss travier 16:33:12 sbrivio: sbrivio 'Stefano Brivio' 16:33:17 #chair sbrivio 16:33:17 Current chairs: PhrozenByte dustymabe gursewak jdoss sbrivio travier 16:33:22 .hello2 16:33:23 jlebon: jlebon 'None' 16:33:52 .hello marmijo 16:33:53 marmijo[m]: marmijo 'Michael Armijo' 16:34:39 #chair jlebon marmijo[m] 16:34:39 Current chairs: PhrozenByte dustymabe gursewak jdoss jlebon marmijo[m] sbrivio travier 16:34:42 welcome all! 16:34:48 .hi 16:34:49 apiaseck: Sorry, but user 'apiaseck' does not exist 16:34:52 #chair apiaseck 16:34:52 Current chairs: PhrozenByte apiaseck dustymabe gursewak jdoss jlebon marmijo[m] sbrivio travier 16:34:53 .hi apiaseck 16:34:54 apiaseck: Sorry, but user 'apiaseck' does not exist 16:34:59 .hi c4rt0 16:35:00 apiaseck: Sorry, but user 'apiaseck' does not exist 16:35:47 apiaseck: maybe try .hello c4rt0 16:35:55 .hello c4rt0 16:35:56 apiaseck: c4rt0 'Adam Piasecki' 16:36:03 Thanks Dusty :) 16:36:14 I think `.hi` is a shortcut for if your IRC nick matches your FAS account username 16:36:39 OK Let's get started 16:36:51 #topic Action items from last meeting 16:37:20 #info there were no action items from last meeting 🎉 16:37:37 can't believe we couldn't find something to assign to @jlebon 16:37:48 :) 16:38:01 can't believe it either :) 16:38:02 * travier looks for something to assign the jlebon :) 16:38:10 to* 16:38:19 though maybe since I pushed the ssh scriptlet over the edge we can find someone else to write up the coreos-status post for the ssh change 16:38:33 * dustymabe thanks @jlebon for the testing on that and review 16:39:16 * dustymabe moves on to `meeting` tickets 16:39:21 #topic New Package Request: passt 16:39:28 #link https://github.com/coreos/fedora-coreos-tracker/issues/1436 16:39:44 PhrozenByte: want to intro this one? 16:39:54 dustymabe: sure 16:40:11 Podman 4.4 introduced the new pasta network mode for rootless containers 16:40:36 it's an alternative to slirp4netns - basically just better (less limited, more performant, etc.) 16:40:49 but it's a rather young project 16:41:10 this ticket is about adding the passt package to FCOS 16:41:44 it's not yet a dependency of podman, but will be with F38+ 16:42:06 PhrozenByte: +1 16:42:21 following your link from https://github.com/coreos/fedora-coreos-tracker/issues/1436#issuecomment-1460437420 16:42:32 takes me to https://src.fedoraproject.org/rpms/containers-common/blob/f38/f/containers-common.spec#_75 16:42:45 where it is listed as a Recommends 16:43:00 so we'll need to add it manually to F38 at least 16:43:20 (though, wow, I didn't know something like "Requires: (passt if fedora-release-identity-server)" was a thing) 16:43:56 we could do the same for the coreos release identity 16:44:16 yeah, I'm mixed 16:44:25 or just include in our manifests 16:44:39 over time it's increasingly clear to me that we need something to classify "server-like" and "desktop-like" use cases 16:45:06 something like "Requires: (passt if fedora-release-identity-server-like)" 16:46:01 PhrozenByte: so in either f37 or f38 today if passt is installed, what neworking stack gets used for rootless? 16:46:03 I'd argue this is useful on Silverlbue/Kinoite & IoT as well 16:46:22 travier: in which case just switch it to a Reqires everywhere? 16:46:39 yes, I don't know why it's not the case 16:46:46 dustymabe: unless you manually specify --network=pasta, Podman will still use slirp4netns 16:46:48 I asked that in the issue 16:46:59 travier: sorry I hadn't caught up completely in the issue 16:47:10 👍 16:47:30 PhrozenByte: and the plan is to eventually move? 16:47:34 dustymabe, during a quick discussion with Podman developers, their intention is to switch to pasta in ~6 months 16:47:34 to make it the default 16:47:46 sbrivio: +1 16:47:50 ah, so that's interesteing 16:48:08 oh, didn't knew that yet, thanks sbrivio 16:48:23 it's ~500kb so that would not be that much to add 16:48:25 timeframe would be somewhere around Fedora 38 release -- let me see if I can fetch a recording from that meeting 16:48:31 but at the same it it's very easy to overlay 16:48:32 sbrivio: PhrozenByte: in which case would probably be good to file a change proposal for F39 (just for awareness) 16:48:55 dustymabe, change proposal for...? 16:49:14 .hi 16:49:15 ravanelli: ravanelli 'Renata Ravanelli' 16:49:50 .hi 16:49:51 bgilbert: bgilbert 'Benjamin Gilbert' 16:50:03 sbrivio: in fedora we have change proposals for changes. it's a good way to publicize a change. hopefully with this one the user doesn't care too much (not much they have to do), but still it's nice to show the project what's going on underneath the surface 16:50:29 for example, here are the ones for Fedora 38 https://fedoraproject.org/wiki/Releases/38/ChangeSet 16:51:03 ok so bringing it back.. it looks like: 16:51:18 1. adding this package yields no functional change without user action 16:51:21 dustymabe, sure, I understand the purpose, but you mean... change to Podman's default (in the Podman code)? or in the package? 16:52:02 sbrivio: either one? I guess for a fedora change what the users care about is what Fedora release it will land in 16:52:18 dustymabe +1 16:52:19 so technically you could change upstream podman without changing the fedora package and no one in Fedora would care 16:53:02 2. the plan is to switch the default later this year (maybe Fedora 39) 16:53:44 i presume even after the default is switched, slirp will still be supported for a while? 16:53:46 So the question becomes: do we ship it early to let folks try it out before podman officialy switches to it 16:53:57 travier: correct 16:54:06 and this is only for rootless containers 16:54:17 so this should not impact rootful containers AFAIU 16:54:40 that's my understanding too (though I will note that 99% of the containers I run are rootless) 16:55:05 Given the small size, and the fact that it requires manual action to get used, I'd say we should include it 16:55:27 travier: yes, to my understanding it would just add complexity without any advantages for rootful, that's why it's for rootless only 16:55:53 I'm not opposed to adding - bgilbert jlebon, thoughts? 16:56:30 seems fine to me too 16:56:30 I guess let me rephrase that 16:56:31 jlebon, I suppose so, it would be supported for a while | travier, right, it's not even possible to use it in rootful mode 16:56:45 I'm not opposed to adding considering we're pre-disposed to carrying it in the future anyway 16:57:03 link to discussion with Podman developers (from Podman Community Meeting) about default switch (it's long, sharing just for later reference): https://youtu.be/qLhf-Ae4jvo?t=1375 16:57:12 The second question would be: should we add it now or wait for F38? 16:57:23 travier: IMO it makes little difference 16:57:28 #link https://youtu.be/qLhf-Ae4jvo?t=1375 16:57:51 it's not a meaningful change without user action so it doesn't matter when we do it 16:58:24 The video mentions waiting for F39 and something missing right now 16:58:28 #link https://podman.io/community/meeting/notes/2023-02-07/ 16:58:56 I'm okay with adding 16:59:15 sbrivio: PhrozenByte: one question I do have is.. when the default migration happens, are there any regressions for users? 16:59:40 i.e. I think for the CNI/netavark switch users had to reset their containers or something 17:00:07 travier, what's missing is possibility to use it for "custom user networks" 17:00:29 dustymabe, in theory not, and I would consider anything like that a bug 17:00:54 sbrivio: good to know. A seamless transition is important to us since our users auto-update 17:01:03 * sbrivio notes 17:01:24 hmm... depending on what is running in the container, I think that software might experience a regression 17:01:49 just think of changing IP addresses. before a container would see a NAT'ed network, with pasta it's no longer NAT'ed 17:01:50 ? 17:02:12 I would be great to get a test for it alongside the change for inclusion. 17:02:15 #proposed We will add passt to Fedora CoreOS. In F37/F38 there will be no functional change to the defaults even with the new package added, but the package is small and it will be the default in the future. Adding it now enables users to get early testing/usage with it. 17:02:24 (We're at the 30 min mark we should wrap this) 17:02:32 PhrozenByte, if there's an explicit migration path, that should also include a change of addresses (pasta can do NAT too, if configured) 17:02:34 +1 17:02:36 travier: agreed, would be nice to have a test for it 17:02:55 ack/nack on #proposed ? 17:03:03 +1 on proposed 17:03:14 sbrivio: yeah, I'd assume that podman would add a migration path to minimize regression 17:03:33 @sbrivio can you notify the podman team that we'll be including it in FCOS so that users can start testing it? 17:03:50 +1 on proposed (especially the "get early testing/usage with it" part which matters to me ;)) 17:03:51 (once/if this is decided here of course= 17:03:54 (once/if this is decided here of course) 17:04:09 travier, sure, I'll do that in a bit 17:04:23 +1 on proposed 17:05:09 #agreed We will add passt to Fedora CoreOS. In F37/F38 there will be no functional change to the defaults even with the new package added, but the package is small and it will be the default in the future. Adding it now enables users to get early testing/usage with it. 17:05:21 i guess we could do it in just next if we wanted to be more careful. but it sounds like it's completely harmless if unused. 17:05:26 +1 17:05:44 yeah, since it's harmless I'd prefer to just get it done with 17:06:09 (to proposed) 17:06:19 now we need someone to do the work :) - volunteers welcome! 17:06:24 i'll move on to the next meeting ticket 17:06:26 +1 17:06:32 #topic Should the QEMU image use ptp_kvm where available by default? 17:06:49 #link https://github.com/coreos/fedora-coreos-tracker/issues/1433 17:07:03 jlebon: go for it 17:07:09 sure 17:09:22 we had a PR that added support for making chrony use ptp_kvm on QEMU by default. ptp_kvm is a kernel module that allows the guest to query the host time so that it may be in sync with it. the main concern with doing this by default is that there's no guarantees that the host time is itself accurate. a tweaked proposal is to keep using the default NTP pool, but with the ptp_kvm added as an 17:09:28 additional source. 17:10:22 there's also a question of trust, but we implicitly default to trusting the hypervisor anyway. in a confidential computing setting, you wouldn't want this. 17:11:02 that's what I was going to say 17:11:33 so the question is: do we want to do this, or should we leave it as a documented item for opt-in (possibly with Butane sugar)? if we want to do this, do we want the first or second proposal? 17:11:35 if we can get something where we can benefit from this source if it's good while keeping a good fallback, that would be best 17:12:19 is the source guaranteed to exist? 17:13:03 my understanding is the module isn't available on all arches. the code opportunistically tries it and if it doesn't work, then exits nicely 17:14:24 I mean the change on it's face seems reasonable 17:14:59 it's specific to qemu, which isn't really a "platform" 17:15:48 any reason we're not doing it for openstack as well? 17:16:09 not sure?? 17:16:37 i'd personally be fine with the tweaked proposal. the "All CoreOS instances on that virtualization platform will be synchronized with sub-millisecond accuracy with each other." sounds desirable. 17:16:48 +1 17:17:31 jlebon: want to throw out a #proposed ? 17:17:40 travier: it might indeed be relevant there too 17:18:02 sure 17:20:42 #proposed we will make chrony take ptp_kvm as an additional source if it's found to be accurate enough. we will add a test verifying that this setup works. 17:21:33 the "if it's found to be accurate enough" part throws me off. Who is doing that check? chrony or us? 17:21:51 chrony 17:22:32 ok 17:22:34 it has a concept of "falseticker". i think that's what the contributor was referring to in the tweaked proposal 17:22:48 +1 17:22:57 +1 17:23:20 * dustymabe notes we no longer have a chrony generator as of https://github.com/coreos/fedora-coreos-config/pull/2271 17:23:35 bgilbert: any concerns with this? 17:24:13 I haven't followed it closely, but none currently 17:24:28 ack 17:24:31 #agreed we will make chrony take ptp_kvm as an additional source if it's found to be accurate enough. we will add a test verifying that this setup works. 17:25:18 ok I had some new changes that we didn't previously consider in https://github.com/coreos/fedora-coreos-tracker/issues/1357 but we're light on time so we'll get to them next week 17:25:23 #topic open floor 17:25:30 anyone with anything for open floor? 17:27:08 #info devconf.cz CFP closes on the 10th 17:27:22 we usually do propose a lab 17:27:30 for newcomers to learn 17:28:03 I'll likely be there 17:28:04 I was thinking about submitting a talk. Obviously the container native stuff is a big change coming and needs some socializing 17:28:23 dustymabe: briefly looking at the remaining changes, i don't think there's anything we need immediate action on 17:28:25 travier: let's get together and organize (if you want) 17:28:33 dustymabe: sure, let's do it 17:28:35 jlebon: +1 so we can handle them next week 17:28:46 I'll submit a talk too 17:29:39 +1 17:30:07 i won't be going to this one, but hope they keep that period for future ones! 17:30:23 👍 17:30:29 have to go. Thanks all 17:30:55 bye 17:30:59 anything else for open floor? 17:31:05 * dustymabe figured jdoss had something 17:31:18 oh hi, yeah I got FIPS working see this issue 17:32:12 https://github.com/coreos/fedora-coreos-tracker/issues/302#issuecomment-1460506911 17:32:16 sorry too many tabs 17:33:18 nice 17:33:23 neat 17:33:40 The changes in F38 to the OpenSSL package make FIPS possible in FCOS, which I think is pretty great. 17:33:40 i think fifofonix was interested in that in the past 17:34:25 encyclopedic @dustymabe. thank you. 17:34:41 np :) 17:34:50 anything else? I'll close out in a minute if not 17:35:14 nothing else, just that FIPS fun time and I wanted to see my FCOS buds. 17:35:51 jdoss: we love you too! 17:35:59 #endmeeting