16:29:12 #startmeeting fedora_coreos_meeting 16:29:13 Meeting started Wed Feb 19 16:29:12 2020 UTC. 16:29:13 This meeting is logged and archived in a public location. 16:29:13 The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:29:13 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:29:13 The meeting name has been set to 'fedora_coreos_meeting' 16:29:18 #topic roll call 16:29:25 .hello2 16:29:26 dustymabe: dustymabe 'Dusty Mabe' 16:30:21 .hello2 16:30:22 jlebon: jlebon 'None' 16:30:55 .hello sinnykumari 16:30:56 ksinny: sinnykumari 'Sinny Kumari' 16:31:03 #chair jlebon ksinny 16:31:03 Current chairs: dustymabe jlebon ksinny 16:31:23 i know we have a few people out on PTO today 16:31:36 bgilbert said he might not be able to make it 16:32:10 I think kaeso[m] might be out as well 16:32:14 O/ 16:32:51 welcome cyberpear 16:32:53 #chair cyberpear 16:32:53 Current chairs: cyberpear dustymabe jlebon ksinny 16:33:37 ok let's get started 16:33:43 #topic Action items from last meeting 16:33:52 * dustymabe to work with x3mboy on FCOS infographic 16:33:54 * dusty to add agreed upon proposal to the ticket and also some points 16:33:56 from the discussion about use cases and what we prefer as the "happy 16:33:58 path" vs what we don't encourage users to do 16:34:01 dusty #fail on the first item 16:34:07 #action dustymabe to work with x3mboy on FCOS infographic 16:34:18 for the second item: 16:34:59 that second action item needs more context :) 16:35:15 #info dustymabe added discussion/use case notes to the wireguard tools ticket: https://github.com/coreos/fedora-coreos-tracker/issues/362#issuecomment-585334830 16:35:21 jlebon: ^^ there it is 16:35:55 jlebon: let me know if there is anything inaccurate in there 16:36:10 yeah, i knew what it was about -- it was just funny how vague it was on its own 16:36:27 indeed, sometimes it's hard to come up with full context statements in the heat of the meeting 16:36:39 I'm better than I used to be at that, but still not great 16:36:49 ok let's move to meeting tickets 16:36:58 +1 i think you captured it really well 16:37:15 #topic Publish the initrd and rootfs images separately for PXE booting 16:37:28 #link https://github.com/coreos/fedora-coreos-tracker/issues/390 16:37:56 it looks like cyberpear weighed in on the ticket too 16:38:27 Yes, in my experience, TFTP transfers are very slow 16:39:04 fun 16:39:13 old trivial transfer :) 16:39:47 Sometimes, it's best to bootstrap iPXE, then chain boot your real PXE from there 16:40:03 But that requires setting up extra stuff 16:40:19 I really want to get out of this without having to deliver multiple sets of ISOs and multiple sets of pxe initramfs options 16:40:20 hmm, so this ticket is asking for publishing the live initrd + a live initrd without the squashfs + the squashfs? 16:40:33 yeah, agreed 16:40:59 maybe a tool to postprocess the initrd to do that split? 16:41:19 i wonder how this worked for CL 16:42:17 the problem is that `coreos-installer` is now not in the initramfs 16:42:30 so delivering just the initramfs is useless from an "install" perspective 16:43:12 commented in the ticket; if we split the rootfs as anaconda does then we'd still fetch `coreos-installer` from the real root 16:43:38 hey walters 👋 16:44:32 .hello2 16:44:33 walters: walters 'Colin Walters' 16:44:42 walters: yeah I agree about similarities with anaconda/stage2 16:44:42 walters: hmm, are you thinking defaulting to that so that we don't also ship a live initrd with the rootfs baked in? 16:45:30 it'd make the PXE setup slightly more complex, but not much so 16:46:15 i lean a bit towards that yeah 16:46:30 ok. good points walters 16:46:45 I see you also linked to https://github.com/coreos/fedora-coreos-tracker/issues/352 which is very relevant here 16:47:16 hmm, actually PXE supports specifying multiple initrds too, so people who want to stick with PXE/TFTP only without HTTP could do that too 16:47:23 I think we should probably evaluate #390 and #352 together and spend some time thinking about our ISO/PXE solution to see what hanges we want to make 16:49:31 #proposed we need to consider our options here for providing installer artifacts and *live* artifacts. There is a slight intersection here with #352. We'd like to take some time to evalute #390 and #352 together and come up with some changes we'd like to make to improve the situation for users. 16:49:45 yep 16:50:15 any opposed? 16:50:19 cyberpear: any thoughts? 16:52:02 ok I assume we're good 16:52:09 next topic... 16:52:40 #topic F32 rebase tracker for changes discussion 16:52:45 #link https://github.com/coreos/fedora-coreos-tracker/issues/372 16:53:21 so what I'd like to do with this ticket is look at the changes proposed for Fedora for f32 and decide if there's anything we need to do 16:53:40 for example: when fedora made a change for cgroups v2, we re-acted by choosing to make v1 the default 16:54:08 #link https://fedoraproject.org/wiki/Releases/32/ChangeSet 16:54:17 anybody see anything in there that is noteworthy ? 16:54:31 `adopting sysusers.d format` - interesting at all? 16:54:45 I know we've had a really long standing issue/PR around sysusers 16:56:07 `Firewalld Default to nftables`: i know we aren't using firewalld but it's noteworthy 16:56:26 but there is: `Make iptables-nft the preferred iptables variant.` 16:56:41 I think we work around sysusers.d it w/ nss-altfiles, but probably we should also set SYS_UID_MAX to 799 to prevent collisions w/ the ostree users and end-user created system users 16:57:30 also of note is the `Limit Scriptlet Usage of core packages` self contained change 16:58:08 walters: jlebon: ksinny: anything you see that's interesting? 16:58:47 iptables-nft is a big one that has the potential to break people's scripts 16:59:33 good point 17:00:17 jlebon: walters: do you know if the sysusers work that we have that is ongoing would fix the issue that cyberpear mentions? 17:00:52 i don't understand that; human users will start from 1000 still right? And all the tooling avoids clashing with existing uids 17:01:40 ok maybe cyberpear and walters can chat in #fedora-coreos after the meeting about this 17:01:48 But system users created by users can collide if latest ostree update includes users not in previous update 17:02:24 I'll add some of our comments here into the ticket for changes for f32 that we consider significant/interesting 17:02:31 Unless we commit to never adding new system users... 17:02:54 so...yes, a lot of subtlety here 17:03:45 sysusers.d solves it, I think. 17:04:49 neat, the sysusers proposal will make the transition smoother for us 17:05:14 jlebon: if we set up a next branch could we just go ahead and take advantage of it and merge some of the outstanding work we have? 17:05:29 cyberpear: the uids match the rest of fedora though for those that are "statically" chosen by decree. there isn't any ostree-specific system user 17:05:36 But it would chown shipped ostree content in case of collision? So maybe still set SYS_UID_MAX lower on installed systemd 17:05:46 *systems 17:07:12 dustymabe: i think most of the work to be done is in rpm-ostree. we need to brush off that PR, rebase it and test it on FCOS/RHCOS 17:07:41 cyberpear: is the problem you describe only a problem on ostree systems? or is this something that would apply to traditional fedora as well? 17:08:04 ostree only 17:08:39 Because ostree ships static uids, not names 17:08:52 ok, maybe an issue would help with a good description. then we can determine if the work the team has done that should land soon will help 17:08:54 (RPM ships names) 17:09:25 ideally more services move to http://0pointer.net/blog/dynamic-users-with-systemd.html 17:09:41 #topic open floor 17:09:46 anyone with anything for open floor? 17:10:03 #info we are really close to having automatic ostree commit import working 17:10:04 also worth noting OpenShift carries code to dynamically allocate uids too, but at a much higher range 17:10:21 cyberpear: probably not worth trying to perfect the hack vs moving to sysusers 17:11:57 dustymabe: 🎉 17:12:04 that's going to be awesome 17:12:11 jlebon: :) scheduled the migration of the ostree repos for tomorrow 17:12:29 dustymabe: nice, is there a link to PR/issue? 17:12:30 so they'll be accessible via openshift and we can import and prune them (from two separate pods) 17:12:50 ksinny: at a high level it's this issue: https://pagure.io/releng/issue/8811 17:13:03 thanks 17:13:08 Combo of sysusers.d aand rpm --setugids (and required --setperms) should fix it 17:13:10 dustymabe: i had a bug to look at, but i can concentrate on https://github.com/ostreedev/ostree/pull/1984 now 17:13:30 * cyberpear wil open bug 17:13:30 jlebon: cool, that should help 17:13:42 jlebon: see also https://github.com/coreos/fedora-coreos-releng-automation/pull/77 17:13:52 I added some checks for making sure our repos don't get out of whack 17:14:07 ack 17:14:15 :) 17:14:35 I'd like to thank ksinny for volunteering to run the release process next week 17:14:48 if all goes well she won't have to ask releng to manually import the ostree commit 17:14:59 thanks for including me in, happy to help with something 17:15:09 ksinny++ 17:15:29 I'll close out the meeting in a minute if no other comments 17:15:47 ksinny++ 17:15:59 I checked Prerequisites permissions and it seems I have all of them <3 17:16:53 #endmeeting