16:29:22 <dustymabe> #startmeeting fedora_coreos_meeting
16:29:22 <zodbot> Meeting started Wed Apr 21 16:29:22 2021 UTC.
16:29:22 <zodbot> This meeting is logged and archived in a public location.
16:29:22 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:29:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:29:22 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:29:27 <dustymabe> #topic roll call
16:29:29 <bgilbert> .hello2
16:29:32 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:30:02 <copperi_> .hello2
16:30:03 <zodbot> copperi_: Sorry, but you don't exist
16:30:12 <copperi_> .hello copperi
16:30:12 <zodbot> copperi_: copperi 'Jan Kuparinen' <copper_fin@hotmail.com>
16:30:44 <jlebon> .hello2
16:30:44 <jaimelm> .hello2
16:30:44 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:30:47 <zodbot> jaimelm: jaimelm 'Jaime Magiera' <jaimelm@umich.edu>
16:31:04 <dustymabe> chair bgilbert copperi_ jaimelm jlebon
16:31:10 <dustymabe> #chair bgilbert copperi_ jaimelm jlebon
16:31:10 <zodbot> Current chairs: bgilbert copperi_ dustymabe jaimelm jlebon
16:31:54 <lucab> .hello2
16:31:55 <zodbot> lucab: lucab 'Luca Bruno' <lucab@redhat.com>
16:32:23 <dustymabe> #chair lucab
16:32:23 <zodbot> Current chairs: bgilbert copperi_ dustymabe jaimelm jlebon lucab
16:33:11 <dustymabe> #topic Action items from last meeting
16:33:11 <dustymabe> * bgilbert to investigate updating the Ignition type registration
16:33:11 <dustymabe> * travier  to summarize outcome in
16:33:11 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/768
16:33:11 <dustymabe> * jaimelm to work on engaging with community on adding .ign/.bu editor
16:33:11 <dustymabe> support
16:33:11 <dustymabe> * jaimelm to file ticket for test day
16:33:11 <dustymabe> * jlebon and dustymabe to write up proposal for
16:33:12 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/785
16:33:12 <dustymabe> will re-action my bit, definitely want to knock it out this time
16:33:19 <dustymabe> #action jlebon and dustymabe to write up proposal for https://github.com/coreos/fedora-coreos-tracker/issues/785
16:33:29 <bgilbert> #action bgilbert to investigate updating the Ignition type registration
16:33:30 <bgilbert> wheeeeee
16:34:04 <jlebon> i think we can reaction travier's as well
16:34:06 <dustymabe> #action travier  to summarize outcome in https://github.com/coreos/fedora-coreos-tracker/issues/768
16:34:41 <jaimelm> https://github.com/coreos/fedora-coreos-tracker/issues/797
16:34:49 <dustymabe> bgilbert: was the type registration thing and the .ign/.bu editor support (from jaimelm) overlapping?
16:34:57 <jaimelm> Just need to decide when to schedule it foir
16:34:59 <jaimelm> for*
16:35:11 <bgilbert> dustymabe: maybe a little, but I'd say mostly not
16:35:12 <dustymabe> #info jaimelm opened #797 to help coordinate a test day for FCOS
16:35:16 <dustymabe> bgilbert: ok +1
16:36:18 <dustymabe> jaimelm: any updates for: jaimelm to work on engaging with community on adding .ign/.bu editor support"
16:36:21 <jbrooks> .hello jasonbrooks
16:36:22 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:36:25 * jaimelm is creating a list of editors that we can check off for supporting the extension.
16:36:35 <dustymabe> #chair jbrooks
16:36:35 <zodbot> Current chairs: bgilbert copperi_ dustymabe jaimelm jbrooks jlebon lucab
16:36:55 <dustymabe> jaimelm: if this is ongoing work it might be worth a ticket to track where you can give periodic updates
16:37:02 <jaimelm> So, there will be list, there will be a communication to the community, and there will be the testing day.
16:37:05 <dustymabe> rather than actions in this meeting
16:37:08 <jaimelm> will do
16:37:31 <dustymabe> #action jaimelm to create a ticket to track text edit updates for .ign/.bu
16:37:43 <dustymabe> Let's move to meeting tickets
16:37:50 <dustymabe> #topic Scheduling future Fedora Test day
16:37:56 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/797
16:38:04 <dustymabe> jaimelm: :) right back to it
16:38:39 <dustymabe> we're currently building a `next` stream build in the pipeline
16:38:40 <jaimelm> Yeah, so when do folks want to do this?
16:38:45 <dustymabe> planning to release it today/tomorrow
16:38:56 <jaimelm> I'll put in the request and update the ticket.
16:39:06 <dustymabe> jaimelm: how about Monday?
16:39:27 <jaimelm> Sure
16:39:45 <dustymabe> anybody with other suggestions/reasons for potential test days?
16:40:16 <jlebon> it's tight wrt GA, but i guess it can't be helped
16:40:30 <jaimelm> Actually, I'm kind of swamped the next couple days – changing jobs. The week after would be better just from my perspective, but I don't want to hold things up.
16:40:44 <jaimelm> also, in terms of reaching the community
16:41:18 <jaimelm> If Monday is what folks want, feel free to take over.
16:41:50 <jlebon> if the goal is to give confidence in the f34 rebase, then it should be before we actually rebase :)
16:42:13 <dustymabe> jlebon: we could do it after GA (i.e. after next week's `next` release)
16:42:44 <dustymabe> but it would be nice to catch things ASAP if we need to investigate and get something fixed
16:43:00 <jlebon> right, it's still useful to have a testday regardless of course
16:43:10 <dustymabe> jaimelm: sorry, didn't know you were switching things up! though interested to hear about it (later)
16:43:37 <dustymabe> so.. before next week's next release or after is the real question IMO
16:43:40 <jaimelm> Project Updates for Community Outreach and Testing for .ign/.bu Changes - #799
16:43:55 <dustymabe> if before, then I'd suggest Monday. If after, then I'd suggest Friday.
16:44:31 <jaimelm> before makes sense
16:45:08 <dustymabe> #proposed we'll schedule and try to run the test day on Monday. Of course contributions are welcome throughout the week
16:45:11 <jlebon> Monday makes sense to give us time to fix things if needed
16:45:40 <jlebon> +1
16:47:11 <jaimelm> +1
16:47:36 <copperi_> +1
16:47:40 <dustymabe> #agreed We'll schedule and try to run the test day on Monday. Of course, contributions are welcome throughout the week.
16:48:07 <dustymabe> jaimelm: i'll try to help fill in the gaps. Sorry about the scheduling conflict. Also, any other volunteers are welcomte to help!
16:48:37 <dustymabe> #topic Actually move iptables to the nft backend
16:48:44 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/676
16:49:04 <dustymabe> jlebon: do you want to do the background for this one?
16:49:24 <jlebon> sure, though might need help remembering details :)
16:49:58 <jlebon> essentially: we're still defaulting to iptables-legacy, we want to move to iptables-nft on new nodes only
16:50:16 <jlebon> the rest of fedora moved over in f32
16:50:55 <jlebon> the sticky issue is that changing defaults for new nodes only is tricky to do
16:51:33 <jlebon> we probably should do this soon because it's long overdue now
16:51:37 <dustymabe> jlebon: and it looks like the potential "upstream solution" isn't going anywhere fast: https://github.com/fedora-sysv/chkconfig/issues/9
16:51:59 <jlebon> right yeah
16:52:32 <jlebon> i sketched a possible solution in https://github.com/coreos/fedora-coreos-tracker/issues/676#issuecomment-732514979 but it's not pretty
16:52:46 <dustymabe> I know zbysek mentioned working on something like this a while ago, but I don't know if that went anywhere
16:53:57 <lucab> gentle reminder that any "new node only" policy doubles the size of the supported matrix. Only with recent topics we already have 4 combinations of [cgroups 1/2, firewall ipt/nft]
16:54:06 <jaimelm> I think that's as elegant that you can get in this situation.
16:54:56 <dustymabe> jlebon: yeah, probably as good as we're going to get
16:54:58 <jlebon> lucab: sadly we had some comments suggesting it's not safe to migrate existing systems
16:55:17 <jlebon> unless i guess we declare it loudly and let users deal with the fallout
16:55:49 <lucab> I don't think that any work on alternatives' future has started in the meantime
16:56:09 <dustymabe> #chair skunkerk
16:56:09 <zodbot> Current chairs: bgilbert copperi_ dustymabe jaimelm jbrooks jlebon lucab skunkerk
16:56:23 <miabbott> .hello miabbott
16:56:26 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:56:28 <dustymabe> #chair miabbott
16:56:28 <zodbot> Current chairs: bgilbert copperi_ dustymabe jaimelm jbrooks jlebon lucab miabbott skunkerk
16:56:28 <jaimelm> letting users deal with it could lead to a pr and functionality nightmare.
16:57:12 <jlebon> maybe it's worth investigating though what it actually entails for e.g. k8s/OKD and docker
16:57:38 <dustymabe> This type of problem is definitely tough to solve.
16:57:46 <jaimelm> sure, I can bring that to the OKD group.
16:58:09 <dustymabe> "possibly unsafe migration for some users" means we try to be more cautious and only do this "only applies to newly deployed nodes" thing
16:58:28 <dustymabe> but lucab is right, it makes it harder to properly cover cases
16:58:34 <jaimelm> yeah
16:58:45 <jlebon> jaimelm: cool, that'd be nice
16:58:52 <dustymabe> jaimelm++
16:59:30 <dustymabe> jlebon: I can only imagine that docker/podman are working fine with it
16:59:41 <jlebon> what we could also do is: migrate on new nodes only, then issue a deprecation window for legacy
16:59:43 <dustymabe> since anyone running that on there Fedora Workstation should have been dealing with it already
16:59:51 <jlebon> after which it's officially not supported anymore
17:00:23 <jaimelm> #action jaimelm bring nft changes to attention of OKD WG/developers for feedback
17:00:24 <jlebon> (and we do a forced migration)
17:00:37 <dustymabe> yeah, that's another option
17:01:01 <dustymabe> but definitely time consuming to keep track of all of those moving pieces (over time)
17:01:10 <jlebon> so basically: migrate new nodes, wait X months, migrate old nodes
17:01:15 <jlebon> yeah, agreed
17:01:20 <dustymabe> just the "keep existing nodes on legacy" is going to take 2 barrier releases already
17:01:46 <jaimelm> jlebon++
17:01:46 <zodbot> jaimelm: Karma for jlebon changed to 9 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:02:20 <jaimelm> that pattern of implment for new nodes, change for older nodes in the future is probably going to be used for a lot of changes moving forward.
17:02:25 <jlebon> dustymabe: the "migrate old nodes" bit in comparison should be much easier
17:02:34 <dustymabe> shall we table this discussion for now, or should we try to draw a conclusion?
17:03:00 <jaimelm> table to get more feedback
17:03:07 <jaimelm> but keep it within the next month or so
17:03:21 <jaimelm> it's apparently been simmering for a whle
17:03:23 <dustymabe> kk
17:03:31 <lucab> dustymabe: how do you envision the relative time of this compared to the cgroup v2 thing?
17:04:01 <dustymabe> lucab: no relation. I just was sifting through bugs and found it (i.e. we've kind of let it linger)
17:04:28 <lucab> I mean, the ordering (sorry I was not finding the proper word)
17:04:29 <jlebon> i'll add a comment in the ticket to see what folks think of the two-phase migration
17:04:49 <dustymabe> ahh, definitely after.. since we've already got a concrete strategy for cgroups v2 hammered out
17:04:58 <jaimelm> cool
17:05:14 <dustymabe> #topic Kubernetes v1.22+ container runtime on Fedora CoreOS
17:05:21 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/767
17:05:40 <dustymabe> still on my plate to dig into this more, but I've left the meeting label on it.
17:06:13 <dustymabe> unless anyone has anything they want to touch on it, i'll skip to open floor
17:06:41 <jlebon> just one thing related to this
17:06:58 <jlebon> i've been working on adding proper module support in rpm-ostree, which should help
17:07:09 <dustymabe> oh, yeah? really nice
17:07:13 <jaimelm> for sure
17:07:27 <jlebon> there's a bunch of things still left to unwind, but it's going well so far
17:07:52 <dustymabe> everyone leave jlebon alone so he can finish!!
17:07:52 <jlebon> <eom>
17:08:16 <jlebon> hehe
17:08:24 <jbrooks> :)
17:08:30 <dustymabe> jlebon: if that's the route we go, then I think the *need* for it might be coming up sooner with kube 1.22
17:08:44 <dustymabe> but sure am glad to hear about it
17:09:09 <jlebon> +1
17:09:29 <dustymabe> #info jlebon has been working on module support for rpm-ostree, which could help us solve the problem here
17:09:37 <dustymabe> #topic open floor
17:10:09 <dustymabe> #info we're putting out a new `next` stream release today and tomorrow that should have all blockers for the f34 rebase addressed
17:10:27 <dustymabe> I don't know of any other blockers ^^ - maybe there are some that should be considered?
17:10:28 <fifofonix> +1
17:12:00 <dustymabe> who all can help us test things on Monday (the test day)?
17:12:27 <dustymabe> we'll make a community blog post about it and try to share it on social media, so if you could share, that would be nice
17:12:56 <dustymabe> I really like what we did last time where we carved up and tested our documentationy
17:13:09 <dustymabe> should we have a video session early in the day to organize?
17:13:32 <jlebon> yeah, that was nice
17:13:48 <jlebon> sure, video WFM if folks are interested
17:13:49 <dustymabe> +1
17:14:08 <dustymabe> looks like we might be done early this time
17:14:15 <jlebon> i don't think there are any other blockers
17:14:16 <dustymabe> 🎉
17:14:25 <dustymabe> will close out the meeting in a few minutes unless discussion continues
17:14:40 <jlebon> nice, it's been a while we did that :)
17:16:08 <dustymabe> #endmeeting