Meeting started at 2024-03-20 16:30:36 UTC

The Meeting name is 'fedora_coreos_meeting'

.hi

!hi

Michael Armijo (marmijo)

.hi

!hi

Dusty Mabe (dustymabe) - he / him / his

!hi

!hi jbtrystram@matrix.org

None (jlebon)

Sorry, I can only look up one username at a time

!hi

Michael Nguyen (mnguyen)

!hi jbtrystram@matrix.org

Sorry, I can only look up one username at a time

!hi aaradhak

Aashish Radhakrishnan (aaradhak)

!hi

Steven Presti (spresti)

!hi jbtrystram

Jean-Baptiste Trystram (jbtrystram) - he / him / his

jbtrystram: you dont need to Hi if you are hosting

or atleast I have never done that

okay :)

Ok I assume everyone is here let's start

fifofonix to bring up a 1.28 cluster with zswap

it does not look like fifofonix is around today

let's re-action this one for next time

I feel it's been re-actionned 5 or 6 times already :)

there were no other actions items in the last meeting

let's start with the topics

!hi

Yasmin Valim de Souza (ydesouza)

actually, let's skip this

the reporter wanted to join the meeting but I failed to get back to them in time to give that info

we forgot to tell PhrozenByte when to join the community meeting

https://github.com/coreos/fedora-coreos-tracker/issues/1690#issuecomment-1995593202

let's see if they can join next week

let's make an action item

https://github.com/coreos/fedora-coreos-tracker/issues/1690#issuecomment-2010024306

ah, you already update the issue. Thanks Jonathan Lebon

let's skip.

i can take this one

so this is related to the cliwrap discussion we had recently-ish

the motivation is the same: to provide a consistent experience when writing Containerfiles to derive from FCOS

so we would ship dnf but it would only work when deriving images ?

the cliwrap approach was intended as a stopgap until we had better dnf support for the client-side, but there were UX concerns with it that made it less appealing

:q

what would happen if i do `dnf` on a running fcos ?

what would happen if i do `dnf install` on a running fcos ? It layers the packages ?

jbtrystram: today, it would be useful in two situations: when layering on the container side, and client-side in an unlocked system (e.g. `ostree admin unlock`)

TIL about `unlock` ! does it break updates ?

today it'll error out with an error about the filesystem being read-only. but there's rough consensus to have it give a more useful error error soon that points to different options (one of them being `rpm-ostree install`)

I think the "client-side in an unlocked system" isn't compelling - that need has always been there and we've never suggested to install dnf to solve that problem before

dustymabe: there have been *many* times when i've directly `rpm -i` packages in an unlocked system to debug things

it's doable today sure. having actual dnf makes it easier :)

Jonathan Lebon: yes, but only now (many years later) have you suggested we should install `dnf` to solve that problem

dustymabe: it's not a primary motivation. i'm just laying out where the gaps are and what works today

agreed. all i'm saying is that if that were the only reason then we wouldn't do this

agreed

reading the linked issue a question comes to mind : if I were to do `admin unlock` then `rpm -i` , the installed stuff would be gone after a reboot ?

so really the reason we should focus on is "make the container installing experience easier"

jbtrystram: yup, exactly :)

There's a hotfix option which will make it persist

jbtrystram: yes, unless you added an option to make it persistent (I think `--hotfix` does that)

Jonathan Lebon: that's a really cool trick to know !!

IMO you really only want to do this on systems you are debugging or developing on and you can easily throw them away after

what's the difference between `hotfix` and layering with `rpm-ostree install` ?

that may be a good question for Jonathan Lebon or jmarrero after the meeting :)

jbtrystram: hotfix permanently modifies a specific deployment

yeah sorry to disrupt

`rpm-ostree install` carries it across updates

Jonathan Lebon: are there any other reasons to install dnf? other than the two you listed?

dustymabe: alignment with the future of bootc, dnf, and rpm-ostree

i'm still not sure clear on what that future is TBH

i'm still not super clear on what that future is TBH

kind of like a soup where things are moving around willy nilly

it's not fully fleshed out, but essentially: client-side logic in rpm-ostree will drain into dnf

dustymabe: making the system more fedora-like as well ? If we want atomic workstations to become the default (something that travier have been working on IIRC) then `dnf` should do something otherwise people will be confused

jbtrystram: but including DNF here won't do that (other than the case where you are building a derived container)

also of note that dnf is shipping in the base bootable images. once we rebase on top of that, we'd have to consciously remove it (and possibly differ from other variants)

I guess that would need to play into our decision to move over to that? which IIUC we haven't discussed anywhere

this seems a little "cart before the horse"ey

for FCOS at least this should at least wait until dnf5 is the default. in RHCOS... well this is going to ship in other variants very soon...

yeah, that's fine. hopefully they don't push off dnf5 to after F41

they've already pushed it quite a bit already

so, i'm trying to keep them to not differ too much, but of course we could also do it in one and hold in the other

ok what's next?

I know there's a lot of uncertainty surrounding this. I think we'll get more clarity in the mid-term at least, but that's where things happening around us are pointing currently.

how about we re-discuss this once the f41 dnf5 change has been approved? i think we need to discuss the RHCOS side too, but we can do that separately

> also of note that dnf is shipping in the base bootable images sre there base bootable image from fedora that we could rebase on ?

> also of note that dnf is shipping in the base bootable images are there base bootable image from fedora that we could rebase on ?

> also of note that dnf is shipping in the base bootable images are there base bootable image from fedora that we could rebase on ?

I'm not the biggest fan of waiting

could we for now install microdnf and symlink `/usr/bin/dnf` to it?

dustymabe: yeah, was thinking about that... possibly? i don't know enough about the gap between the two. but one thing i tested was that even the fedora-minimal image doesn't use microdnf

so i'm not sure where it's in active use

k - so probably has issues, or at least if there are issues it won't get fixed

```[core@cosa-devsh ~]$ sudo microdnf install htop Package Repository Size Installing: htop-3.3.0-3.fc40.x86_64 rawhide 200.2 kB hwloc-libs-2.10.0-3.fc40.x86_64 rawhide 2.2 MB Transaction Summary: Installing: 2 packages Reinstalling: 0 packages Upgrading: 0 packages Obsoleting: 0 packages Removing: 0 packages Downgrading: 0 packages Is this ok [y/N]: y Downloading packages... Running transaction test... error: Error -1 running transaction ```

it does ship dnf5 though. so possibly dnf5 renders it obsolete?

(e.g. i mean `fedora-minimal:39` ships dnf5 today)

interesting.. didn't know that

could we just pick up and use dnf5 then (since it's obviously built for f39/f40)?

I think it's used in redhat `ubi` images

dustymabe: we could... i do like though the signal we get from it being the default in Fedora

i would really like also to have `dnf install` output a more useful error message before we add it to FCOS

my initial goal with this discussion is more about having rough alignment of where we're going. there isn't anything actionable right now. if we agree to ship it in f41, great! but I'm also OK re-discussing that when there's more clarity.

well, i guess we could add it to the rawhide stream now

I imagine we could actually ship this in rawhide already and make it conditional on F41?

yeah

we could say "we'll add it in f41 and rediscuss at branching"

I assume rawhide is dnf5 already?

i'm not sure. i'll check

not in `fedora:41` at least

ahh, good to know

ok, wrap up this topic?

ok here's my proposal and we'll see what comes out: proposed: we will add dnf5 to the rawhide stream to test it out and help shake out issues. we will re-evaluate at f41 branching.

ok here's my proposal and we'll see what comes out: proposed: we will add dnf5 to the rawhide stream to test it out and help shake out issues. we will re-evaluate at f41 branching whether to continue with it or hold off.

that seems fine to me, though I'm not sure about "re-evaluate at f41 branching whether to continue with it or hold off" -> we need a mechanism to make us re-evaluate if we really want to re-evaluate remembering to re-evaluate, probably won't work well

we can add it to the f41 checklist (which we can file now)

ack, nack? the faster we vote, the faster we move on :)

+1

+1

+1

might be worth including our reasoning for including DNF in the agreed

or maybe the conversation in the ticket is sufficient

so 1 action to add dnf to rawhide, and 1 action to add to f41 checklist to rediscuss it

jbtrystram: you can assign those to me. i can also take care of posting the agreement in the ticket after the meeting, where i'll add more details about some of the things we discussed

!agreed: @jlebon will add dnf5 in the rawhide stream to test it out. We will add to the f41 branching checklist to reconsider this and evaluate at this point in time

the semicolon prevent the bot to pick it up. Before I confirm this, no objections ?

yeah probably need to drop the colon

we are running out of time. Should we carry on or push the remainings topics to the next time ?

i think let's just do an open floor

the reporter of the next issue is not here I think

Any other topics to discuss ?

we do have a test day coming up (assuming we get a Beta GO this week)

ash, jbtrystram how's that coming along?

The Fedora test week is now rescheduled to the first week of April

We are at the stage of shipping next as part of the tasks under Fedora 40 beta

We are at the stage of shipping rebased next as part of the tasks under Fedora 40 beta

ok, if no one else as anything I'll end the meeting shortly