16:30:56 #startmeeting fedora_coreos_meeting 16:30:56 Meeting started Wed May 27 16:30:56 2020 UTC. 16:30:56 This meeting is logged and archived in a public location. 16:30:56 The chair is lucab. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:30:56 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:30:56 The meeting name has been set to 'fedora_coreos_meeting' 16:31:01 .hello2 16:31:05 cyberpear: cyberpear 'James Cassell' 16:31:13 .hello2 16:31:14 slowrie: slowrie 'Stephen Lowrie' 16:31:16 .hello2 16:31:17 #topic roll call 16:31:18 jlebon: jlebon 'None' 16:31:23 oh yeah, circular dependency 16:31:24 .hello2 16:31:25 bgilbert: bgilbert 'Benjamin Gilbert' 16:31:30 #topic roll call 16:31:31 .hello2 16:31:33 coremodule: coremodule 'Geoffrey Marr' 16:31:34 .hello2 16:31:36 lorbus: lorbus 'Christian Glombek' 16:31:37 .hello2 16:31:39 kparal: kparal 'Kamil Páral' 16:31:42 .hello2 16:31:43 jdoss: jdoss 'Joe Doss' 16:32:14 #chair bgilbert jdoss kparal lorbus cyberpear slowrie jlebon 16:32:14 Current chairs: bgilbert cyberpear jdoss jlebon kparal lorbus lucab slowrie 16:32:31 .hello sohank2602 16:32:34 skunkerk: sohank2602 'Sohan Kunkerkar' 16:32:46 #chair coremodule skunkerk 16:32:46 Current chairs: bgilbert coremodule cyberpear jdoss jlebon kparal lorbus lucab skunkerk slowrie 16:33:28 .hello sumantrom 16:33:29 sumantro: sumantrom 'Sumantro Mukherjee' 16:33:44 #chari sumantro 16:34:14 * #chair sumantro 16:34:26 #chair sumantro 16:34:26 Current chairs: bgilbert coremodule cyberpear jdoss jlebon kparal lorbus lucab skunkerk slowrie sumantro 16:34:36 lucab: third times the charm 16:35:07 slowrie: eh, editing message from Matrix does not work well in IRC ;) 16:35:20 anyway, let's start 16:35:31 #topic Action items from last meeting 16:36:10 1. lorbus to try out OKD on our `next` stream so we can work out any kinks before switching `stable` to f32 16:36:30 2. cyberpear to take a look to see if we can change the libicu dep in samba-client-libs to a recommends (#452) 16:36:45 3. bgilbert to PR c-i and f-c-c SOP for new signing key 16:37:14 for 1. I've seen Vadim's comment at https://github.com/coreos/fedora-coreos-tracker/issues/372#issuecomment-632174381 16:37:41 #info bgilbert PR'd signing key to c-i, dustymabe PR'd to f-c-c 16:38:14 for 2. I've seen some movement at https://github.com/coreos/fedora-coreos-tracker/issues/452 16:38:50 so I think nothing too strange on F32, and for unicode data still going on? 16:39:55 yeah, not sure if it's worth pursuing that one further 16:40:13 (that one = item 2) 16:41:04 item 1 is still WIP. 16:41:11 I'm not too concerned. Yes it's big, but it's a library and it can be dropped freely in the future (hopefully) 16:41:47 yeah, true 16:41:57 lorbus: ack, I think we have the F32 switch as one of the next topics 16:42:09 so let's just go to that 16:42:27 #topic F32 rebase 16:42:35 #link https://github.com/coreos/fedora-coreos-tracker/issues/372 16:43:28 jlebon: I think you were pointing to https://github.com/coreos/fedora-coreos-config/pull/394#issuecomment-634776712 16:43:59 right yeah. accordign to the schedule we agreed to last week, the next testing release should be f32: https://github.com/coreos/fedora-coreos-tracker/issues/372#issuecomment-631586457 16:45:19 bug-wise, there's https://github.com/coreos/fedora-coreos-tracker/issues/496 which is worrisome. i'm looking into this now, though i don't think it will be made worse by the f32 move 16:46:42 that's a regression on our side anyway, it can't get more broken 16:46:49 (famous last words) 16:47:27 there's also https://github.com/coreos/fedora-coreos-tracker/issues/488, which has a backport workaround already in next-devel, so that should be ok too 16:47:46 apart from those, AFAIK we're in a good position 16:48:19 jlebon: so the ostree in F32 is fixed too right? 16:48:27 yup, indeed 16:49:03 I think we can merge #394 once CI is green today/tomorrow 16:49:09 unless anyone has any concerns with the next testing release being f32, i'd say let's merge https://github.com/coreos/fedora-coreos-config/pull/394 on green 16:49:18 lucab: heh :) 16:49:29 are there any other bits to tweak for a fedora-major bump? 16:49:31 +1 16:49:40 +1 16:49:52 * kparal notes this topic is related to https://github.com/coreos/fedora-coreos-tracker/issues/491 16:49:53 +1 16:50:06 lucab: there's the releng key signing thing we'll need to take care of 16:50:33 kparal: you are right, I should have tackled that first 16:51:15 jlebon: can you reference that in #372 so that we don't forget to do it 16:51:19 i guess we can move to that topic? 16:51:41 yes, let's just say not technical blocker to rebase testing to F32 16:51:51 lucab: yup 16:51:58 #info no technical blocker to rebase testing to F32 16:52:17 (by "that topic" i meant test day, to be clear :) ) 16:52:20 #topic Fedora Test day for our `next` stream (Fedora 32) 16:52:28 #link https://github.com/coreos/fedora-coreos-tracker/issues/491 16:53:05 kparal: here you go 16:53:15 OK, hi all, we talked to Dusty and offered to help you run a FCOS 32 test day. It might be a good PR for you, and not only a way to find some bugs, but also identify documentation or user experience issues. There is a document to do some brainstorming about possible test cases here: https://hackmd.io/lX41BH4TSlqDGqgwr_xWVg?edit 16:53:36 and sumantro set up a preliminary test day results page here: http://testdays.fedorainfracloud.org/events/84 16:53:56 it links to draft testcases (or documentation directly, when we haven't managed to create testcases yet) 16:54:01 kparal: do we have to pick a day for this or is it already set? 16:54:09 kparal: that's great 16:54:17 you can pick any date you want, sumantro might have some suggestions 16:54:24 lucab, we need to pick a date 16:54:25 it depends how much in a hurry you are 16:55:05 I think we'd like to switch testing to F32 for the next release 16:55:09 and any suggestions on specific things to test/testcases are very welcome 16:55:10 the testcases are not finished yet, and they will need help from your side, because you're the ones who know fcos stuff, we don't know the technical details that much :) 16:55:15 which would be next week 16:56:07 testing can be switched to next before or after this test day, that doesn't really matter I think (unless you want to detect some bugs before switching it to testing) 16:56:15 but it should happen before you switch it to stable :) 16:56:32 hmm, maybe we should do it between f32 hitting testing and stable 16:57:09 as kparal said, we are not coreos experts, so your expertise on what should be tested and help developing test cases is much appreciated 16:57:10 having it in testing for test day would make it easier for participants 16:57:35 I don't know which target date Dusty had in mind 16:57:40 I already reported on issue related to this test day, so you might expect more "ux" feedback like this, which is I think beneficial: https://github.com/coreos/fedora-coreos-tracker/issues/493 16:57:42 *one 16:58:15 but I think we can more or less target the second half of next week, after testing release 16:58:52 right yeah. or even early in the week of the 8th 16:58:54 kparal: +1, we need more reports of that kind 16:59:22 heh, we should probably fix that for test day 16:59:36 lucab, does 12th sound good to you all? 17:00:01 the testcases are in fedora wiki, anyone logged in can edit them (I believe), please help us shape them up. Or you can put the steps into the hackmd document and we'll convert it to wiki. Just have in mind your target audience, it should either reference documentation or list concrete steps so that even beginners can try them (unless the testcase is for advanced/expert audience only) 17:00:43 sumantro: I think as jlebon suggested, 8th or 9th would be better 17:01:02 awesome then 8th sounds great 17:01:24 sumantro: because I guess the stable switch would be around the 16th 17:01:51 #info tentatively scheduled test day on June 8th 17:02:40 anything else on this topic? 17:03:03 I guess a general request for "come up with more manual test scenarios" 17:03:30 I'll also include a test case for some exploratory testing (do what you want) and documentation review 17:03:47 so it doesn't need to strictly be just manual testing in the narrow sense 17:04:13 but yes, we need ideas in the hackmd document and implementation of those ideas in wiki or again in the hackmd document 17:04:41 ack 17:04:47 thanks, that's all from me :) 17:04:53 maybe we can split the testcases among us to fill out? 17:05:03 anyway, we can discuss that after :) 17:05:10 kparal: thanks! 17:05:41 last one is from my side 17:06:19 #topic network interface name 17:06:30 #link https://github.com/coreos/fedora-coreos-tracker/issues/484 17:06:53 (I should probably retitle this ticket with something better) 17:07:09 I was digging into this yesterday/today 17:07:35 I think we made a mistake some time ago and we didn't realize for quite a bit 17:08:03 we assumed that `.link` units are used by systemd-networkd 17:08:24 and we purged both sides from FCOS images 17:09:04 it turns out both code and docs agree that they are used by udev, to (among other thing) rename interfaces in a persistent way 17:09:23 and that's my investigation so far 17:09:51 fixing it for new images can be done by just removing a -config line 17:10:21 I think there is consensus that it may break static config on bare-metal on auto-updates 17:10:47 so we should at least try brainstorming a bit more 17:11:57 my gut feeling is that 1) we want to eventually use persistent names for new nodes 2) we care a bit about trying not to break everything if we can 3) we are not in a super-hurry to solve this (i.e. not next release) 17:12:03 s/next/upcoming/ 17:12:33 I'd like to argue with 3 17:13:15 OKD is planning to go GA in 1-2mo. I'd like to solve this before that happens 17:13:39 3) assumes that we can keep old nodes on old names, and new nodes on new names 17:13:54 agreed, would be best to solve in time for OKD GA, or otherwise, patch it OKD side if necessary 17:14:32 does OKD itself care about what's the name of an interface? 17:15:14 not really, but I'd rather not find out about any implications of this after GA 17:15:56 fair 17:16:13 it makes it harder for OKD users to write network configs i suppose 17:16:25 so the ballpark ETA for this is, after F32 but before OKD GA 17:16:49 lucab: i think we had a suggestion that should work for the majority of existing nodes, right? 17:17:54 jlebon: I still need to sleep on it a bit more, but yes some kind migration script (writing a file) and a barrier to force node through that 17:18:47 hmm, actually, i think just adding a net.ifnames=0 karg in the migration script would cover it, no? 17:19:07 ^ so we may end up w/ a barrier for the F32 upgrade after all 17:19:09 jlebon: kargs are a bazooka, but yes 17:19:14 we can chat about it in the other channel if you prefer 17:19:48 cyberpear: subtly different, we place barrier whenever we need, not explicitly on major bumps 17:20:00 we did something similar for cgroupsv1/2: https://github.com/coreos/fedora-coreos-config/pull/238 17:20:16 right; just happens to be adjacent to a major bump here 17:20:31 cyberpear: if they happens to be the same release, it's fine, but a coincidence 17:20:42 jlebon: yes, I'll keep adding stuff to the ticket 17:20:58 +1 17:21:30 lorbus: when is OKD tentative GA? (roughly) 17:21:52 lucab: Mid July 17:22:22 ack 17:23:26 #info barrier for netnames pinning script should better be in place for mid-July for OKD GA 17:23:43 ok, I think that's all 17:23:51 #topic Open Floor 17:24:09 wrt https://github.com/coreos/fedora-coreos-tracker/issues/452 and the extra 32MiB added: supposedly https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking should have helped, but that was an F30 change, so apparently didn't actually help 17:24:27 ^ just a comment, nothing further from me on it 17:24:48 lorbus: isn't minimization also hitting this? 17:25:36 once/if they look at SSSD, or other packages that are impacted, but I don't know SSSD has been a target of Minimization specifically yet 17:25:43 hm I'm unaware of this 17:26:29 cyberpear: when i briefly looked at it, it did seem like libsmbclient was actually using the library and not just linking unnecessarily 17:26:30 perhaps it's worthy bouncing it there just as a FYI 17:27:10 +1 17:27:29 +1 17:27:55 minimization: https://pagure.io/minimization/issues https://docs.fedoraproject.org/en-US/minimization/ 17:27:58 unless anything else, I'll close in a few seconds 17:28:16 thanks all! 17:28:23 thanks! 17:28:35 #endmeeting