16:30:14 #startmeeting fedora_coreos_meeting 16:30:14 Meeting started Wed Jul 28 16:30:14 2021 UTC. 16:30:14 This meeting is logged and archived in a public location. 16:30:14 The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:30:14 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:30:14 The meeting name has been set to 'fedora_coreos_meeting' 16:30:19 #topic roll call 16:30:22 .hi 16:30:23 dustymabe: dustymabe 'Dusty Mabe' 16:30:48 .hello2 16:30:50 jlebon: jlebon 'None' 16:30:54 .hi 16:30:55 darkmuggle: darkmuggle 'None' 16:31:43 .hi 16:31:44 bgilbert: bgilbert 'Benjamin Gilbert' 16:31:50 .hello sohank2602 16:31:51 skunkerk: sohank2602 'Sohan Kunkerkar' 16:31:57 .hello siosm 16:31:58 travier: siosm 'Timothée Ravier' 16:33:19 #chair jlebon darkmuggle bgilbert skunkerk travier 16:33:19 Current chairs: bgilbert darkmuggle dustymabe jlebon skunkerk travier 16:34:27 ok let's get started 16:34:53 * dustymabe was hoping jaimelm would be here today 16:35:03 #topic Action items from last meeting 16:35:09 we only had one action item from last meeting 16:35:17 * dustymabe to re-index and look for newly submitted change proposals for f35 that we need to consider 16:35:20 #chair saqali_ 16:35:20 Current chairs: bgilbert darkmuggle dustymabe jlebon saqali_ skunkerk travier 16:35:40 I did not manage to do that so I'll pick it up again 16:35:48 #action dustymabe to re-index and look for newly submitted change proposals for f35 that we need to consider 16:36:20 #topic Fedora 35 changes 16:36:27 #link https://github.com/coreos/fedora-coreos-tracker/issues/856 16:36:45 it looks like a few items got closed out since last week 16:36:53 #link https://github.com/coreos/fedora-coreos-tracker/labels/F35-changes 16:37:01 the openssl one is a known quantity 16:37:24 .hello2 16:37:25 walters: walters 'Colin Walters' 16:37:25 darkmuggle: want to toss the sssd one to someone else since I think you're going AFK? 16:37:31 welcome walters :) 16:37:36 #chair walters 16:37:36 Current chairs: bgilbert darkmuggle dustymabe jlebon saqali_ skunkerk travier walters 16:38:13 looks like Jaime isn't here today to speak to the CompilerPolicy change 16:38:30 jlebon: correct - i emailed him last week and he said he was looking into it, though 16:38:41 so hopefully we'll hear back soon 16:39:19 though looks pretty low risk. it's designed to be a no-op by default 16:39:32 anybody else want to pick up the sssd investigation (assuming darkmuggle hasn't done investigation in the background already)? 16:39:47 specifically: https://github.com/coreos/fedora-coreos-tracker/issues/875 16:40:10 I've done some looking, but haven't really been able to dig since Jenkins is being Jenkins 16:40:19 oh jenkies :) 16:40:27 How soon does that need doing ? 16:41:00 not sure exactly but since you're going to be out for some time figured I'd try to find a volunteer 16:41:30 not critical though 16:41:46 * dustymabe will move on to the next topic soon 16:41:53 if someone wants to grab it I won't complain 16:42:04 otherwise, it will wait till early Aug 16:42:45 i'm going to skip the "documentation style guide" topic since jaimelm isn't here 16:43:06 and oomd I think is already mostly decided - i'll try to add a comment there 16:43:11 * lorbus is late and waves hello 16:43:11 .hi 16:43:11 lorbus: lorbus 'Christian Glombek' 16:43:15 welcome lorbus 16:43:19 #chair gurssing lorbus 16:43:19 Current chairs: bgilbert darkmuggle dustymabe gurssing jlebon lorbus saqali_ skunkerk travier walters 16:43:24 welcome gurssing 16:43:31 .hello miabbott 16:43:31 miabbott_: miabbott 'Micah Abbott' 16:43:36 #chair miabbott_ 16:43:36 Current chairs: bgilbert darkmuggle dustymabe gurssing jlebon lorbus miabbott_ saqali_ skunkerk travier walters 16:43:48 #topic not too distant future FCOS work 16:44:13 #link https://hackmd.io/iSsyF255SO2hfDlTv1diXQ?edit 16:44:36 it's been a while since we've taken a high level view of the work we'd like to do 16:45:12 I created a new hackmd document and copied the text from the last time. Let's discuss what is no longer relevant and also what we want to add to the list 16:45:30 please make updates to the doc below the "Make updates below this line" line 16:46:13 For example - item F is done now (kernel arguments) correct? 16:46:34 F is done 16:46:35 also item P (openstack in CI) is done now 16:46:52 is H done? 16:46:59 Q is done 16:47:02 item A [multi-arch POC] is almost done :) 16:47:14 H [make a rawhide stream] is done!! 16:47:15 C is done 16:47:39 J is done 16:47:42 we've done things! 16:47:49 C[root reprovisioning] ✅ 16:47:53 wait sorry, i've been editing the hackmd directly... 16:47:53 :) 16:48:05 jlebon: yeah that's fine 16:48:10 ahh ok :) 16:48:11 under the updates line 16:48:22 we're just collaborating here to note or ask if something is done 16:48:36 what about D? the release notes workflow? seems like that has fallen out of priority 16:49:25 miabbott: yeah that kind of dropped when allen left 16:49:26 .hi 16:49:27 lucab: lucab 'Luca Bruno' 16:49:35 #chair lucab 16:49:35 Current chairs: bgilbert darkmuggle dustymabe gurssing jlebon lorbus lucab miabbott_ saqali_ skunkerk travier walters 16:49:51 yeah... probably belongs under "Removed from immediate consideration" 16:49:54 I added some new items at the very bottom (with hopefully unique letters) 16:50:07 meta: i think that we're noting so much as done is worth calling out in release notes ;) 16:50:20 🤣 16:50:38 bgilbert: where did we stand on R? 16:50:52 R[stable root image size] 16:51:09 we just need to switch to making it a hard error now i think 16:51:35 jlebon +1 - so that's probably low effort, maybe something we can do soon? 16:51:35 yeah, and there's also an open Butane issue to warn if it notices that the rootfs is being constrained 16:52:05 dustymabe: right yeah 16:52:17 cool 16:52:27 walters do we know where I.[bootupd] stands? 16:53:04 not high priority right now I think 16:53:40 maybe M.[ongoing work to keep streamlining our release processes] is too generic and can be removed? 16:53:50 yeah +1 16:53:57 we actually did do a bunch of stuff in that area 16:54:11 so it's more half-done half-deferred. definitely still a lot left to do 16:54:38 any discussion that we should have about the remaining items left over from last time? 16:54:58 sysusers package layering sugar etc.. 16:55:06 K. is related to the container image work 16:55:13 yep 16:55:20 so it's partially being worked on I guess 16:55:38 ok let's talk about the new items and where we think they land 16:55:53 V. dnf counting is something we should be able to complete in august 16:56:02 i'll move that to in progress 16:56:34 is there anything tracking fcos-as-edition? 16:56:58 walters: good question, I don't know of a ticket. I think cverna was trying to head up that effort 16:56:59 X and Y aren't new-new but I think they're worth considering again; lmk if that's out of scope 16:57:12 bgilbert: not out of scope at all 16:57:46 wanted to talk about modularity also and https://github.com/coreos/fedora-coreos-tracker/issues/910, which would feed into this planing process 16:57:54 #action dustymabe or cverna find ticket or create new ticket for efforts to become an official edition 16:58:01 jlebon: add it 16:58:52 fcos as an edition fesco ticket was closed a while ago - https://pagure.io/fesco/issue/2516 16:59:50 miabbott: yeah, i think it's worth us tracking it too (with links to all the various happenings) 17:00:16 ok let's try to move the other items to consider into the 3 earlier bullets 17:00:26 none of it is in progress per se 17:00:30 other than dnf counting 17:00:53 so out of those items any we should promote to the "not yet being worked on" state 17:01:03 which to me implies, we'd want to start on it soon 17:01:39 W. is kind of a "collaboration with other parts of the Fedora community" piece 17:01:41 yeah, i find that confusing. can we rename it "todo" or something? 17:02:02 jlebon: added ",but soon" 17:02:11 ok, better :) 17:02:12 but feel free to change the heading to something more appropriate 17:02:25 also still looking into extending platform support on my side. Waiting on them to get further along 17:02:40 we should really do S soon I think 17:02:53 jlebon: +1 yeah I think so too 17:03:14 I think gurssing1 is going to help us with that one 17:03:14 it's a recurring talking point in various discussions 17:03:25 and we'll need to make appropriate announcements to the community 17:04:28 regarding U. it would be nice to do that sooner than later - especially since we have to make announcements 17:04:45 do we have opinions on grouping changes that need announcements together 17:04:58 for example nft, oomd, zram, all need some communication to happen 17:05:13 would it be better to group them together (share barrier releases, etc) or do them separately? 17:06:21 sharing barriers makes sense, yeah 17:06:34 bgilbert: lucab: might have some opinions here ^^ 17:06:55 as long as it doesn't make logistics too complex and error-prone 17:07:20 I don't think it's critical that we group them if that makes things much harder 17:07:28 bgilbert: agreed 17:07:57 so we can say. if it's not hard to group them, it makes sense to do so (for efficiency), but otherwise, leave them separate? 17:08:07 it's usually safer to decouple invasive changes, because there is often something not going as expected and bisecting through multiple changes is harder 17:08:17 lucab: agreed 17:08:44 the question is.. how hard is it to track multiple in flight community notices etc.. as an end user 17:09:16 this ties in with the k8s docs a bit 17:09:22 if we send out an email today about nft. and another in a month about oomd+zram.. then there are two changes to track with different timelines 17:09:26 i.e. we could have an "upcoming changes" dashboard in docs 17:09:30 communications can be unified, without barriers being so 17:09:48 jlebon: ahh, maybe a good compromise 17:10:00 lucab: ^^ 17:10:10 bgilbert: that would be nice to have 17:10:12 bgilbert: that's a neat idea 17:10:39 bgilbert: can you create a ticket for that? 17:10:54 #action bgilbert to file a ticket for an "upcoming changes" dashboard 17:11:02 perfect 17:11:03 that's also a good place to put a summary of past changes 17:11:15 e.g. we have the PXE rootfs transition docs in a random place right now 17:11:36 +1 17:11:51 ok so one final question.. we should do T.[documentation for k8s distributors ] before these breaking changes land? 17:12:26 but not necessarily before the communications go out to warn of them 17:12:26 👀 17:13:38 ok so the question is should we move T. and U. to the "soon" column and if so who would like to sign up for those changes? 17:14:46 https://travier.github.io/fcos-progress-reports/ > We kind of need something like that 17:14:48 and I guess.. are we OK with N. and G. in the "Removed from immediate consideration" column? 17:14:57 yes to that from my side, but I don't see it as critical if not 17:15:06 Maybe make a doc site out of the tracker repo like we did for other projects? 17:15:27 travier: yeah that is really nice, though maybe a little more verbose than the "upcoming changes" that benjamin proposes 17:15:59 Yes, this was a direct conversion from the Council reports. We can start fresh and make something simpler / clearer 17:16:00 dustymabe: let's move them and we can discuss assignment separately? 17:16:06 (re. T & U) 17:16:10 travier: maybe that intersects with D (release notes) 17:16:12 dustymabe: +1 to deferring N & G 17:16:17 jlebon: +1 17:16:31 i think bgilbert would be great for T :) 17:16:39 I'd love to see sysusers support (N), but removing from immediate consideration is probably reflective of its priority TBH 17:16:40 This would be really close to release notes indeed. 17:16:58 #assign bgilbert T. (based on jlebon's comment) 17:17:13 hehe 17:17:14 🤪 17:17:26 I don't actually have much of the context for T 17:17:26 I'll make a draft for a Release notes / upcoming change page 17:17:45 thanks travier 17:17:49 #action Make a draft for Release notes / upcoming change page 17:18:06 ok X. proper DigitalOcean support 17:18:24 DO is a pretty common platform for developer experimentation and it's awkward that we don't have native images there 17:18:28 i've talked to them about promoting us and switching us over to have DHCP enabled 17:18:45 they said we'd lose Floating IP support, but we already don't have it 17:18:56 (custom image workflow doesn't have FIP support) 17:19:02 dustymabe: oh interesting, I didn't realize DHCP was even an option 17:19:22 I think it is (darkmuggle would know more) 17:19:39 my understanding was that it only works for custom images 17:19:39 (I have an FCOS instance on DO and the current workflow was easy to use although not fully integrated indeed) 17:19:54 this route sounded better to me than the other route (more work) :) 17:20:02 but yeah let me check back with them 17:20:18 +1 17:20:41 dhcp is and contains a good route 17:20:46 bgilbert: if it turns out my intel was wrong then we might be back in the "networking trickery" camp 17:20:55 walters: haha 17:21:04 hehe 17:21:05 The floating IP doesn't sound right 17:21:22 I trust you dustymabe, but that is weird IMO 17:21:38 dustymabe: nm-cloud-setup now exists. that might be the right place to support their metadata service, though we'd still need to bring up LL networking 17:22:03 darkmuggle: do you remember (i think it was you who told me) that it should be easy to enable DHCP for just a subset of their default images? 17:22:10 we could have DO use the Config Drive meta-data and then use the OpenStack images 17:22:26 yeah, we just need to tell them to flip a bit in their database 17:22:33 it sounds like a "DHCP in VPC" only mode? 17:22:37 I know because I've done it 17:22:39 cool 17:22:54 bgilbert: agreed 17:23:05 lucab: nope, not the reason 17:23:15 ok Y. - disable serial console by default (on bare metal, i think) 17:23:16 NDA precludes me from explaining that 17:23:38 "soon" or removed from immediate consideration 17:23:51 on the RHCOS side we recently had another bug caused by serial-by-default: https://bugzilla.redhat.com/show_bug.cgi?id=1985030 17:23:58 bgilbert: is there a document tracking what actually is missing in FCOS for DO networking? 17:23:59 darkmuggle: the floating IP I mean, which I don't remember coming up in previous discussion 17:24:05 this continues to be a pain; I think we should think about fixing it 17:24:29 jlebon: the DO enablement ticket has it. mostly it's that standard images don't have DHCP by default 17:25:00 or we go the Cloud-init route and do an `ip4ll` up command on DO 17:25:03 ironically I've seen the been use of the serial console default today, here: https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-vmware/#_troubleshooting_first_boot_problems 17:25:18 *the best 17:25:22 we still routinely have to explain to users that they need to disable serial console to see their Ignition failure 17:27:26 i had recently looked at this. commented in https://github.com/coreos/fedora-coreos-tracker/issues/567#issuecomment-877229856 that maybe it needs more investigation 17:27:36 lucab: are you arguing against serial console changes? 17:28:32 maybe this is a bit of a rat hole for this particular meeting and.. we're running out of time 17:28:41 dustymabe: no, it's overall a pain. I was just amazed to discover this only today. 17:29:06 got ya 17:29:09 ok moving on 17:29:11 #topic open floor 17:29:32 2 FCOS talks accepted and scheduled for Fedora Nest! 17:29:32 wow that discussion of topics and priorities was much more productive than I thought it was going to be 17:29:45 thanks all for participating in that 17:30:09 #info aarch64 progress in the pipeline is being made. hoping to have images building this week 17:30:33 #info rpm-ostree modularity support is now merged! https://github.com/coreos/rpm-ostree/pull/2760 17:30:40 what.... nice! 17:30:43 this has implications for the cri-o discussions, which i need to follow-up on 17:31:07 it also has implications for RHCOS, which i also need to follow-up on 17:31:22 anything else you need to follow up on :) 17:31:32 :) 17:31:46 * dustymabe is reminded of a systemd bug we need to chase 17:31:56 my memory is fading!!! 17:32:01 ok we're over time 17:32:14 will close out in 60s unless we have other topics 17:32:20 shhhhh, please forget that bug again 17:33:12 #endmeeting