Meeting started at 2024-02-21 16:34:37 UTC

The Meeting name is 'fedora_coreos_meeting'

.hi

.hi c4rt0

.hi!

It's been just a week and I can't remember the correct way of welcoming the bot...

!hi c4rt0

Adam Piasecki (c4rt0) - he / him / his

Lol I understand

!hi jbtrystram

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

.hi gursewak

Ok lets wait a few more mins for people to roll in

!hi gursewak

Gursewak Singh (gursewak)

!hi

None (jlebon)

!hi

No Fedora Accounts users have the @aaradhak:matrix.org Matrix Account defined

(fyi, I just added a meeting label to https://github.com/coreos/fedora-coreos-tracker/issues/730)

!hi aaradhak

ah

Aashish Radhakrishnan (aaradhak)

well we can tackle that one first so I dont miss it

Well lets start

!hi fifofonix

Fifo Phonics (fifofonix)

.hi

!hi

Dusty Mabe (dustymabe) - he / him / his

Jonathan Lebon: would you like to introduce this?

sure!

Thank you

so basically, we had agreed to this a while back but never actually executed on it

Yeah ok, thats what I was thinking based on the comments.

I'm proposing actually executing on it now as part of the f40 rebase

well. we agreed to experiment with it and then added stipulations on actually fully implementing it

> AGREED: We will turn on cliwrap in the FCOS next stream to gain feedback. We will document it, and send an email to coreos-status. We will file an f35 Change before turning it on on all streams (as well as possibly other rpm-ostree variants like FSB and IoT).

the reason for bringing this us is that as part of the bootable containers work, it would be really nice if users could actually type `dnf install` in their Containerfiles

i'm fine with following that recommendation if preferred. though i guess the change would have to go into f41 at this point, which is a while

i'm fine with following that recommendation if preferred. though i guess the change proposal would have to go into f41 at this point, which is a while

but also, I'd like to do this in RHCOS soon, and ideally RHCOS and FCOS match in this respect

So to be silly here, if we did it as a part of the f40 rebase, what are the consequences?

it would bake together with the f40 rebase. so in branched first, then next, then eventually GA

it would bake together with the f40 rebase. so in branched first, then next, then eventually stable

Sorry, I am asking more of what are we losing by changing the manifest files

From this comment, it seems low impact on dev, https://github.com/coreos/fedora-coreos-config/pull/830#issuecomment-781596771 but what impact does it have other then adding the functionality?

it's not changing anything that doesn't currently work. it's essentially adding wrappers for dnf, dracut, and grubby (the latter two are just simple bits that say "hey, you should use rpm-ostree $x instead")

Ok, so from the sounds of it, I am certainly for adding it to the f40 rebase.

does it change dnf in just the building container case or for all of FCOS?

both the container case and client side

ehh, ok

this is still far, but note that eventually it's possible we ship dnf5 in FCOS, at which point we would undo parts of this

obviously lots of things to discuss/flesh out before that

i'm ok with an advanced timeline. I liked the change proposal approach because it raised visibility

but w/e at least it's new and shouldn't break anything (I think)

Ok, so it sounds like we have two proposals lets vote between them.

one thing i can imagine breaking are things that check for `/usr/bin/dnf` before `/usr/bin/rpm-ostree` instead of e.g. `/run/ostree-booted` or `/etc/os-release`

but hopefully we find those out as part of the branched and next baking

all for proposed: Enable cliwrap with f40 rebase

yeah that's a good point

i will abstain from voting :)

there's an ansible role that may start breaking now.. not sure, but we'll find out

All for proposed: advanced timeline, propose enablement of cliwrap for f41

yeah, want to type it out?

do you mean f40 ?

does the cliwrap do the `ostree commit` that's needed in containerfile when doing native stuff ?

does the cliwrap do the `ostree commit` that's needed in containerfile when doing native containers stuff ?

The second one , is the change proposal for f41

jbtrystram: no, that's separate. the cliwrapped dnf essentially just redirects to rpm-ostree for a few commands (e.g. `install`, `upgrade`)

sorry if I am sucking at elaborating well on this.

it feels a bit half baked to allow users to do dnf install in containerfiles if they still have to do ostree commit ?

spresti: probably less complicated to vote on one proposal at a time. so e.g. you can do a proposed for the f40 one and we see the outcome?

Sure :)

Ok sorry all, lets start that over

proposed: Enable cliwrap with f40 rebase

+1

well, they're separate things. the ostree container commit bit is actually optional nowadays IIRC the dnf wrapper gets us closer to what people are used to.

+1

+1

+1

+1 - we'd need to communicate this to our users: https://github.com/coreos/fedora-coreos-tracker/issues/1655

+1

okay, cool to know it's optionnal

+1

Okay voting ending in 30 seconds for this.

dustymabe: i'll add it to the ticket

proposed: make a change proposal for f41 with cliwrap

+0

hmm. I don't see the point

making a change proposal for something we already implemented is kind of shirking the process

unless we want to enable it in other variants

Ok; I guess we can go with option one then :) Voting ended for second proposed

Thank you Jonathan Lebon for that

Ok moving to the next topic

I think most folks will love that in the desktop variants :)

Altough the change already exist somewhat : https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable#rpm-ostree_dnf/yum_CLI_compatibility

apiaseck: would you mind introducing this ?

I would have to go through this first - don't have enough info from the top of my head on the subject.

Ah ok I saw you added the meeting topic so I thought you might.

No worries, sorry to put the pressure on you lol

yeah sorry, apiaseck tagged it on my behalf while we were discussing it live

i can take this one

Ty

so essentially, we discussed this a while back but at the time didn't enable it because notably k8s didn't support it well

and we were gating on adding more docs for k8s distributors/users to undo this sort of stuff (together with the oomd change)

it seems like nowadays, k8s plays nicer with swap which makes this easier to do. the goal is to try to match Fedora

but... let me doublecheck what the status of the feature is in latest k8s

ok no change in 1.29 that i can see, so presumably still a beta feature

anyway, no rush on this but it stuck out in backlog refinement as a delta that we're still carrying

rather an alpha right?

https://github.com/coreos/fedora-coreos-tracker/issues/859#issuecomment-1733652634

Jonathan Lebon: could you update the ticket with what you found?

should we just saw we'll implement swaponzram (i.e. match Fedora) when its no longer beta?

should we just say we'll implement swaponzram (i.e. match Fedora) when its no longer beta?

maybe. the other approach is we tie it to e.g. the f40 rebase and add docs (linked from communications too) for how to disable it

which i think is closer to where we were going originally with https://github.com/coreos/fedora-coreos-tracker/issues/880#issuecomment-884565096

ehh. I think that "single node defaults" thing never quite picked up enough steam

i'm not sure if I would carry that here - we never really did the work there

yeah, the proposal there is more involved. anyway, we don't have to linger on this. but essentially my 2c is: i think we probably should just turn this on with sufficient notice to match Fedora and provide docs to turn it off.

I'm not really strong enough opinion to block any of these changes; just don't think much has changed since we originally talked about them

I would love to get closer to matching Fedora in the long run - 100%

yeah, exactly. :) nothing changed, so this is just taking the easier approach

what I don't want to do is break people.

which I guess rolling it out on `next` first would do

indeed. it needs to be communicated properly.

like if we know everyone who has a kube cluster who hasn't enabled this beta feature is going to break.. that's not great

which would be an argument for waiting to roll it out when it's no longer beta

but we also don't want to hold back changes forever

as someone who runs `next` i would want clear communication.

but also, I run `next` to help validate things for you guys, and not to slow the train

i think we need to clarify what the failure mode is currently with the beta support even if not enabled

Sounds good. I think bringing that new information to the ticket will help us make a more informed decision at least

ok, let's move on

Agreed, should we make an action item for this?

if someone could bring up a 1.28 cluster on a systems with swap on that'd be really helpful :)

Any takers (nogoes for me) ?

(i may be able to help but not in the next two weeks while i ski and then it will be busy when i'm back etc)

Thank you fifofonix

fifofonix: that'd be amazing. i don't think there's any rush on this.

open floor?

We still have two topics lol

We might need to push them to next week.

there's always next week

i'm out. sorry. have a call with someone.

Thank you all for such a good discussion, def a surface I have not thought about before.

Any topics for OD ?

I have one

Go for it?

we have F40 beta coming up.. we'll need to create a test day ticket and organize a test day like we have in the past. it would be great if a motivated person or two could organize it.

spresti: that's it from me

Thank you dustymabe

I would be more than happy to help anyone who is willing to run it.

oo sounds more like a volunteer

I would like to volunteer for the test day

awesome!!!

Well with that, if there is nothing else.

I will end todays meeting

Thanks for running spresti

ash: apiaseck can you look to Renata Ravanelli for guidance? I think she ran the last one