Meeting started at 2023-12-13 16:29:14 UTC

The Meeting name is 'fedora_coreos_meeting'

!hi dustymabe

Dusty Mabe (dustymabe) - he / him / his

!hello c4rt0

Adam Piasecki (c4rt0) - he / him / his

Hi all!

!hi jlebon

None (jlebon)

!hi gursewak

Gursewak Singh (gursewak)

!hi fifofonix

Fifo Phonics (fifofonix)

welcome apiaseck Jonathan Lebon gursewak fifofonix

!hi jdoss

Joe Doss (jdoss)

!hi aaradhak

Aashish Radhakrishnan (aaradhak)

I am still figuring out this Matrix stuff.

welcome ash jdoss

we all are

welcome Brad Smith 🙂

ok so @jlebon and I went over the existing accepted changes for F40 yesterday

A decent number of them were items that we had already discussed previously but had been deferred from F39

Lots of exciting changes in F40

All the ones with the ✔️ are items we think won't require any work from us

I'll go through real quick the ones that we didn't come to any conclusion on

subtopic 105. Ostree Native Container (Phase 2, stable)

this one is from Colin and it was deferred from F39

So no more Zincatti upgrades in FCOS? Am I reading this right?

he's been working on bootc related stuff and also possibly pushing that up into Fedora more properly. I think they will probably write a new change proposal and this one will get replaced

jdoss: I don't think that has been decided anywhere

>Rework Fedora editions and spins (CoreOS, IoT, Silverblue, Kinoite, etc) that use ostree to instead deliver via Docker/OCI container images Is why I asked.

yeah, even if we deliver via a container registry (which we do plan to do), that doesn't mean zincati (or similar functionality) goes away

Gotcha, sounds good.

great to see this will be progressing. do we see any improved ux with this turn of the wheel or is it generally behind-the-scenes stuff?

Zincati (and the update graph) at its core is not very ostree-backend specific

Jonathan Lebon: anything you want to add?

~~Jonathan Lebon: anything you want to add?~~

dustymabe: no, i think that's good :)

fifofonix: a lot of behind the scenes stuff for the most part. but something we would really like to do is enable automatic updates even if you have derived and rebased to your own container layer - it's not an easy problem to solve, though :(

fifofonix: i think we're still figuring out how this will get phased at a higher level than FCOS

phased in*

moving this forward.. what do we do with this particular Changes entry for now? mark it as "likely to be replaced with updated Fedora 40 strategy" and move on?

I would really like to see some Ignition sugar added to bundle layer images into ISOs and manage that whole lifecycle.

yeah, i don't think we need to focus on it as part of the change proposal process since it has its own dedicated focus

but this is fantastic that it is considered stable. I have been using it for over a year and I have had very little issues.

Jonathan Lebon: what should we put under the `Notes:` entry for it?

dustymabe: i think Colin had created a tracker issue for it in the past. we can point to that for now and say more info to come in the future.

let me try to find it

@jdoss great to have your feedback on stability. i demoed the feature to my team this week as i think we're going to finally make this pivot in my world. researching the topic i was happy to see it referenced in OKD documentation at this point too.

ok I'll move on and let jlebon send me the notes to add to this entry

jdoss: great to have your feedback on stability. i demoed the feature to my team this week as i think we're going to finally make this pivot in my world. researching the topic i was happy to see it referenced in OKD documentation at this point too.

subtopic 112. Switch pam_userdb from BerkeleyDB to GDBM

Jonathan Lebon's notes were: `NOTES: jlebon: NEEDS INVESTIGATION. looks like they expect users to run a conversion tool`

so maybe we add an individual tracker issue for this and get a volunteer to look at it?

yeah, sounds good +1

subtopic 118. Removing SSSD ‘files provider’

Jonathan Lebon's notes were `NOTES: jlebon: should be transparent to us, but this touches nsswitch.conf, which is sensitive`

another tracker issue?

i think this is just "make sure that the nsswitch.conf change looks sane"

in case of a bad change, the most likely case is that it'd break CI (by breaking altfiles), but would be good to be sure

yeah, SGTM

ok - any other of these topics in the list that we should discuss? maybe there is one where we missed some detail and we do need to investigate?

ok I'll move on to another topic

so there is a change for this already but I don't think it's been accepted yet

i think basically there's not much we can do there other than make users aware

basically it looks like podman v5 is going to be really hard to upgrade to

i think as soon as it's accepted, we should send something out. they can use the new defaults today to ensure no breakage at rebase time

Jonathan Lebon: but that most likely means removing/recreating all containers?

yes

or just reprovisioning, with newer bootimages, or tweaked ignition config

fifofonix: jdoss ^^

catching up

oh man, this is a doozy

i think if you've provisioned in the last couple of releases, you should already be good

All good changes tho

personally this doesn't seem to be a major issue for me. my podman containers can be redeployed entirely without issue.

maybe we should do some analysis to see what versions are affected

I think I am fine, I basically keep on stable and we redeploy the container images on layer update from tarballs.

but yeah, you're probably right jlebon about if your systems are new enough it might just be OK

i don't recall when we switched over to cgroups v2 by default, but basically the max of (f36, $cgroups_v2_release)

when was boltdb switched out?

hmm, i don't *think* boltdb is getting cut out yet, just deprecated IIUC

CNI was default in f35 and older

ahh ok

(to be verified)

so CNI and boltdb are just deprecated

no

CNI support is getting removed

oh, the change proposal doesn't say that

No longer support cgroups v1 Deprecate CNI plugins Deprecate Boltdb Have passt as the default rootless network service instead of slirp4netns Support stable --format Go template structs Isolate podman bindings leading to improved usability Allow better handling of containers.conf

https://fedoraproject.org/wiki/Changes/Podman5#Upgrade/compatibility_impact

yeah, i think "Deprecate CNI plugins" in that section probably should be "Remove support for CNI plugins" ?

ok then the bullet points probably need to be updated mboddu ^^

Ack

I will update it

so cgroupsv2 and CNI are getting removed - boltdb still around but deprecated

But yes, CNI support is getting removed

ok good to know

so yeah, I guess we can start today with CLM helpers and instructions for people (I guess as soon as the change gets accepted).

so yeah, I guess we can start today with CLHM helpers and instructions for people (I guess as soon as the change gets accepted).

at least the CLHM helpers will still be there when their nodes get moved to Fedora 40 and they log in to find out why they aren't working

I wish there was a migration that could be done, but I don't want to put our team on the hook for that. mboddu do you know of any tooling that will move a system over without having to delete containers and re-create them?

I can't imagine for RHEL that we'd make people delete their containers on upgrade, but maybe if it's a major upgrade

I am not aware of anything like that, if there is then we could change the "Deprecate boltdb" to "Remove boltdb" :)

mboddu: is the second bullet in https://github.com/coreos/fedora-coreos-tracker/issues/1629#issuecomment-1854387360 accurate?

Jonathan Lebon: I am not sure on the fedora releases, but the info is accurate

mboddu: thanks!

ok I need to step away soon. I'll move to open floor

anyone with anything for open floor?

I guess we should bring up the meeting schedule for the next few weeks

I'll be on holiday until the new year so won't be able to attend any meetings until jan 3rd

Have a great holiday Dusty (and everyone else too!)

should we cancel the remaining meetings for the year, or does someone want to carry the torch?

+1 to cancel

+1 to cancel

yeah agreed

+1 to cancel too

We do need to find a candidate to run the releases next week :) - apiaseck - looks like you are assigned to them. Are you going to be around?

Oh yes, I'm around

I'll do it gladly (hopefully with no issues)

ok that's all I had

will close out the meeting in 60s unless new topics arise

Toodles everyone 🙂