Meeting started at 2024-05-29 16:32:43 UTC

The Meeting name is 'fedora_coreos_meeting'

!hi

!hi aaradhak

Timothée Ravier (siosm) - he / him / his

Aashish Radhakrishnan (aaradhak)

!hi

Hristo Marinov (hricky) - he / him / his

!hi ravanelli

Renata Ravanelli (ravanelli)

!hi

Michael Armijo (marmijo)

!hi

Dusty Mabe (dustymabe) - he / him / his

!hi

Joseph Marrero (jmarrero)

I can see three action items in the meeting minutes:

1. ravanelli to contact the libteam maintainers to figure out if they intend to drop the package from fedora

!hi

!hi

None (jlebon)

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

Renata Ravanelli: do you perhaps have any update on this?

for those who have acces see: https://issues.redhat.com/browse/RHEL-22999?focusedId=23924774&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen[…]924774

I reached out the libteam team and the understanding is that they will keep it in Fedora, for those who have acces see:

The comment: "Oh, if kdump is just indirect depending on libteam, I think we can close this issue now (Please make sure the kdump code can handle the teaming deprecation). Marcelo Leitner Please correct me if I made any mistake. There is no need to drop NetworkManager dependency. We will ask NM and Anaconda teams to help remove their dependents.

libteam will not be removed on Fedora."

Thank you!

Any comments on the above?

https://github.com/coreos/fedora-coreos-tracker/issues/1727#issuecomment-2108521808

so we'll have to decide if we want to keep it or not

we apparently have a test for it

if it's not removed from fedora I don't see any good reason to remove it from FCOS ?

true, at least we don't have to do it now

true, at least we don't have to do it now / for F41

i'm mixed on this

i think a middle ground approach is to ask our users: "is anyone using this?"

if we don't get any hits then I'd say we can reasonably remove it

if we get a few people pop up then we can just keep it

that would unnecessarily break somone who missed the communication

we'll need to make a CLHM warning for it, send announcement, etc. if we want to remove it

as long as it's in fedora what's the cost of keeping it?

jbtrystram: right.. but we must be able to make some breaking changes over time, right?

longer ci because we run a test for it and potential ci / bugs

If remove from fedora yeah, let's ask people and consider the CLHM ...

longer ci because we run a test for it and potential future ci / bugs

maybe a self contained change request to raise awareness

we can bundle it with the 41 rebase and have it part of the communications

though I'm really OK with either decision

dustymabe: sure ! but i don't really see why we should drop a package from $upstream because $downstream_distro we use to build $internal_product is a valid reason :)

I'd say: let's wait and see how things goes. If it starts breaking and we need to spend time on it then we can reconsider?

no strong opinion from my side. feels like a lot to do CLHM + announcements though, which is why i'd suggest piggybacking on f41 if we do this

jbtrystram: it's likely that "support" will be limited moving forward and testing may as well be reduced

jbtrystram: I think the reason for me would be "because we don't think anyone is using it". if evidence came to light that disproved that I would have a different opinion

jbtrystram: to compare, you'd have to see if NetworkManager-team is installed by default in Fedora Server

so it may be that "matching Fedora" is actually to remove it by default, but users can always layer it back on (that's usually not easy for network-related things due to bootstrapping issues, but... I don't _think_ that's a concern here for teaming/bonding?)

I feel Jonathan Lebon suggestion is the lowest effort approach : keep it but add a note on F41 release that we'll remove it in F42 if nobody scream

(low effort is a positive adjective here :) )

that's what we "tried" with the wifi firmware for F40 and we ended up doing the CLHM work

we don't announce the change, we don't feel good "just" dropping things

yeah, though that one came in late into the f40 cycle

jbtrystram: i actually meant removing it in f41

travier: but we are dropping wifi for the f41 cycle..

yes, because we did the CLHM

right 👍️

I think it's quite useful.. it hit one of my boxes here at home and I took the appropriate steps

keeping it in is maintenance work, ripping it out is announce/CLHM work

we should have some sugar in our overlays or something to make it easier to write CLHM dropins. it's a bit of a pain and boilerplate-y right now

hmm. i thought it was pretty easy

If we have volunteers to do the work to remove it then we can do that, otherwise maybe let's wait until this becomes an issue?

it's basically lots of copies of the same systemd unit template and script file. the only thing that really changes is "what to check for" and "what to write in the MOTD dropin".

travier: SGTM

maybe we can just enumerate what we think the "work" is to remove it?

so that someone can pick it up if they are inclined

2. Write a CLHM

1. Send an announcement to ask for users and warn on planned removal if no answer in X weeks?

3. Announce the removal as part of Beta rebase in next

4. profit?

3. Announce the removal as part of Beta rebase in next

4. profit?

1. Send an announcement to ask for users and warn on planned removal if no answer in X weeks?

2. Write a CLHM & do the manifest changes

4. Profit?

Suggestion:

1. Send an announcement to ask for users and warn on planned removal if no answer in X weeks?

2. Write a CLHM & do the manifest changes

3. Announce the removal as part of Beta rebase in next

Just a gentle reminder on the time we're spending on this discussion. Should we discuss it further next week?

I'd just say post the above in the ticket probably

proposed: We will remove teamd support from Fedora CoreOS provided there are no active users and the work listed above is completed

+1 from me

ack

+1

+1

+1

(but... i feel like we need to work on lowering the overhead on making minor breaking changes like these)

+1

let's move to the next topic?

Action item No.2:

Jonathan Lebon to file a butane issue to discuss improvements around device names

Ah, yes .. sorry

https://github.com/coreos/butane/issues/532

Thanks Timothee

This one is good :)

next action :)

:)

for the next action

Jonathan Lebon: Could you introduce the above?

(expand on)

I think we can move to topics

apiaseck: did you forget to change !topic?

We were discussing action items ...

Or so I thought 😕

(those actions items were only about us filling issues to track things so we should be good)

👍️

I think those don't need more discussion

hmm, I don't think we need to discuss this here. we can move to the tracker topics (tagged with the `meeting` label)

Ok, let's move on to python discussion.

I said most of what I had to say on this topic a few weeks ago. Not sure if I can add much. The summary of my position is that we either make more work for ourselves OR miss funcionality we would have otherwise included by keeping python based software out of FCOS.

interested to know if anyone was able to come up with any shifting positions based on further thought

i'm ok with this, highlighting again (like Dusty did previously) that each package should be reviewed on its own. i think with more resources it'd be great to keep pursuing the original vision, but... that's not where we are

> i think with more resources it'd be great to keep pursuing the original vision, but... that's not where we are

I think this is a key point here ^^

According to me, we have to be aware that there is likely no going back. It's very unlikely that we'll ever be able to remove it once we add it

travier: I think you are probably right

though we could try to stick to that as an option

But agree it's the path of least resistance

and try to bring it up often in the discussion

one idea i had was to add some preamble for interactive python to warn that there's no intent to keep user workloads stable and e.g. python packages might come and go. users will still use it of course, but at least they might be more aware of the risks

ehh. I think i'd prefer to not do anything special if we do include it, but I guess we could debate that too

and also at the very least document that stance in our docs

is your vote for inclusion (or rather non-exclusion) conditional on something like that @jlebon ?

should we do a proposed on this topic?

i don't know if i'd block on it, but i think it wouldn't be very hard to do this

i'm pretty sure we will see people file bugs/topics about their python scripts no longer working after updating to version X. we need to be ready for that. the preamble is more of a way to try to catch them earlier on (knowing it won't catch them all)

!proposed we will no longer exclude packages that require python from Fedora CoreOS. If we decide that we want the package in Fedora CoreOS we will include it, even if it's dependency chain includes python.

ack (though would be good to at least add the docs part)

I'm still conflicted on this, so I don't know what to vote.

@travier +0 ?

+1 from me (to state the obvious)

lots of other people around... thoughts?

I feel like your statement from the topic dustymabe `I argue that excluding python has caused us more work/pain than if we had just included it.` convinced me to vote +1

From my (more or less) user point of view, and if my opinion counts, +1.

its a +1 for me on including python.

Everyone's opinions count Hristo Marinov. Thanks for the vote!

Renata Ravanelli: jbtrystram want to weigh in?

its a +1 from me on including python.

We're running out of time - it's probably a good idea to get to a conclusion...

+1 for me too

its a +1 for me on including python.

Its a +1 for me on including python.

In that case I think we agreed on the above...

Any last votes before ending the meeting?

apiaseck: you good to do the agreed or do you want me to?

I'm good

Is there anything else pressing?

Hope everyone is having a good week!

I hope everyoin enjoy they're time off! ;)

Thanks for attending everyone!

Thanks for running apiaseck

I hope everyone is enjoying they're time off! ;)