Meeting started at 2025-07-30 17:00:21 UTC

The Meeting name is 'fedora-server'

I'll post the agenda in 2-3 minutes.

As usual, let's wait a moment for everybody to show up.

!hello

Steve Daley (mowest)

!hello

Emmanuel Seyman (eseyman) - he / him / his

!hello

Paul Maconi (aggraxis) - he / him / his

Hi Steve, hi Emmanuel, hi Paul! And Hi nirik I guess you are lurking as usual :-)

I think, we can start.

Anything to add or to remove?

It's probably enough. It's been a while since we gathered.

Yeah, indeed. Lets start.

topic 1. Follow-up actions & announcements

Nothing new regarding actions.

I'll participate at FrosCon in Germany, 16./17. August. There is a Fedora / CentOS booth.

I guess, I'll be the only one of us :-)

quite probably :-)

Anything to add here ?

That's awesome! I hope it turns out to be fruitful, or at least fun!

Yes, I thing at least fun, to meet many Fedorians

No tracking issue yet

Just one suggestion before we begin: When we comment on things like this in general discussions on Fedora-devel or similar channels, we should avoid anything like “voting” with +1 / -1 And we should always point out that we will discuss it in the server WG and will and must agree there on a final solution or decision. Otherwise, this could easily lead to misunderstandings.

It's been a while since I read the proposal (I'm just back from vacation) but it felt reasonable

There are 2 proposals. One about optical media, one about BiosBoot. BiosBoot is a bit more complicated.

The proposal is for whether or not either condition is release blocking, right?

Yes. Lets start with optical media.

I was mainly thinking about the optical media proposal

Sorry, wrong link!

https://discussion.fedoraproject.org/t/proposal-drop-optical-media-boot-release-criterion/160524/2

The gist is, we still use a filesystem that can be transferred to a DVD, but we give up the blocking status, if something goes wrong with a DVD.

Yes, I was in favor of this, because even on the old systems that I am running Fedora Server on in my homelab I haven't installed with a CD or DVD since 2009.

indeed

OK, yes, therefore

proposal: Server WG agrees to change proposal regarding optical media as the proposal suggests

proposal: !agreed: Server WG agrees to change proposal regarding optical media as the proposal suggests

+1

+1

+1

+1

OK, we all agree.

!agreed: Server WG agrees to change proposal regarding optical media as the proposal suggests

zodbot ????

poor thing's gone feral

Oh, zodbot doesn't like a colon.

Second proposal ist about installation procedures

gist is, on BiosBoot systems it is only blocking a default installation, i.e. One Disk with the unmodified File system.

That is not enough in my opinion. As I argued on Matrix, various root server (bare metal) provider have to use BiosBoot besause their admin and maintenace infrastructure currenly needs it. Therefore my proposal, blocking status for default file system *and* sinple Raid1 file system as described in our documentation.

And we need blocking for this, otherwise Server would not be installable for a full release cycle.

My question with this: Who would be responsible for testing a RAID1 file system install, and who would determine if it is release blocking?

testing is our issue, or better mine, because I'm the one with the testing equipment.

I was in favor of this proposal, because it would at least allow me to do a default install which some of my old machines still require, and then I can make modifications or add disks to my install after the install process.

And are we talking some kind of software raid or something done by the controller? Because if the kernel has a driver for the controller and it's doing the RAID1, what is there really to test here?

I wouldn't expect someone to test my RAID install of Fedora Server because I like to use btrfs as my RAID filesystem.

If they tested HW RAID 1 on UEFI it's most likely going to work on BIOS as well.

There is to test, it it works :-) The critical issue is the placement and handling of the biosboot partition. Everything else is equal.

The Anaconda team worked on this specifically on our asking.

Yes, hardware raid is beyond our testing. The issue is software raid, preferred by many over hardware raid at least in 2 disk situations,

I don't really have an issue either way. If they strip out most of the BIOS test cases but leave in enough to satisfy the RAID requirement that's probably still good for the QA folks.

Yes, I hope so. Because the testing of this item is our problem. It has to be done manually.

As far as I know.

Another problem is, out LibVirt configuration defaults to BiosBoot.

Do we feel this is a big enough deal to hold up the whole release of a Fedora version, that is another concern of mine.

I think, it is on one level with the default file system. And raid is really a classical Server thingy

I feel like release blocker issues would be nice if they were ones that could be tested by more than just a small group of Fedora users who have the right equipment.

Yeah, therefore we want to make a test day or a test week. To engange more people as our WG.

We probably need to see what the testing procedure for this is anyhow so we can replicate the scenario.

Right now I don't have a visual on what it is I'd need to do to see if this does or does not work.

Mostly because I stick to a default partitioning scheme for Fedora in my typical use case.

I'm unsure how many of us would have the hardware to test. I have old boxes that I need to use BIOS install with, but I don't often have more than one drive in the box, and if I do I don't always do RAID on those boxes either.

Well, the test case is, pick a BiosBoot Server system and follow the instruction of our documentation. We did that for at least the last ten releases and found issues as well as no issues.

vips6349

Welcome John! what is vips?

I thought I was in another window. Sorry for the noise

OK :-)

OK, so the proposal is:

roposal: !agreed Server WG rejects to change proposal without an addition of simple, default software raid installation as described in installation documentation.

proposal: !agreed Server WG rejects to change proposal without an addition of simple, default software raid installation as described in installation documentation.

+1

I mean it seems reasonable enough

We have the authority to reject change proposals? I thought only FESCO could do that

Oh yeah. We'd have to make some kind of statement/comment to the proposal

Yes, Fesco decides. On the other hand we are the ones, who "own" the product and have do decide about it.

I would be okay with "Server WG requests the addition of simple, default software raid installation as described in installation documentation to the change proposal. "

I don't interpret the change request as removing functionality, just QA will no longer test and possibly block release.

That’s the nicer phrasing. I agree.

proposal :agreed Server WG agrees with the proposal on the condition that a simple Software Raid installation in accordance with Server documentation.is added with blocking status.

proposal !agreed Server WG agrees with the proposal on the condition that a simple Software Raid installation in accordance with Server documentation.is added with blocking status.

Then I don't have a problem supporting the change request. I also have old BIOS stuff, but without any Raid. If I find an issue with BIOS and raid, I can always submit a bugzilla. They are pretty responsive to regressions.

The testing is not the issue. Testing was always manually by Server WG or someone else. The important thing is blocking in case of problems.

The updated language looks good to me.

I'm okay with that proposal

John Himpel: The problem is, if a non-working version is released, there is no progress on this for the complete live of that release, because we don't update distribution media. And therefore blocking is important!

I don't want to be a barrier to a group concensus (sp?), so I'll abide by the majority's desires.

OK, I see no objection to the second version?

OK, then

Anything else to add here?

I see none. Lets proceed

Tracking issue: !link https://pagure.io/fedora-server/issue/164

I did some (manual) testing of x86 installation with default file system and raid1. And fount no issues, so far.

Any other results?

Unfortunately, I missed to add the results to the test matrix.

We should do that in any case!

I haven't done any F43 testing yet. I feel like I just got everything updated to F42 :-)

Yes, I'm busy with update the last of my servers from 41 to 42, too.

Can / could someone test VM installation? or SBC?

I can do VM testing. The July 8th image listed in the issue?

Does QA do automated VM installation? I wouldn't want to duplicate automated testing.

and where / how do we report results?

I should be able to do both (but not this week)

The latest test case is https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250728.n.1_Server

I have to update the issue :-)

This Coconut person is EVERYWHERE on that matrix! lol

Does someone know the branch date out of the head?

Yeah, he is, or better it is. it is the test bot.

We just got the notice that the mass rebuild completed 2 days ago.

I see, branch freeze is August 15. We should have tested one of the various instances until then.

Well, out time is up. So is there anything left to discuss now?

No I'm good for today.

I plan to go through the change proposals and flag those that interest us

aggraxis gave a cookie to eseyman. They now have 18 cookies, 1 of which were obtained in the Fedora 42 release cycle

(Pg 18 being the default, ...)

I'm good? I think. I hope. :)

Emmanuel Seyman: Oh yes!! I forgot this item.

There is the dovecot thing

I'll try to do this by our next meeting

OK, so I'll close, it nobody intercepts.

3

2

1