Meeting started at 2026-05-13 17:00:33 UTC

The Meeting name is 'fedora-server'

!group members server-wg

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

Welcome to our weekly Server WG meeting.

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

!hi

Jocelyn Gould (UTC-4): Jocelyn Gould (korora) - she / her / hers

!hi

MatH: Mat H (theprogram)

!hi

Petr Sklenar: Petr Sklenar (psklenar)

morning. gonna try and be around today. :)

!hi

abbra: Alexander Bokovoy (abbra) - he / him / his

OK, let's start

There were no additional comments in our Matrix room, so I think we can stat.

https://docs.fedoraproject.org/en-US/server-working-group/wg-minutes-2026/

meetings overview:

Regarding the action, see the list in our

Announcements:

I Update our dnsmasq Doc. Would be nice to have a review soon. Currently, there is a note that the final review is missing.

Just another topic: In Forgejo, you can organise labels into groups. I’ve started doing this on a trial basis for documentation, projects and Ansible. Please [have a look](https://forge.fedoraproject.org/server/tickets/issues). It doesn’t actually help get the work done, but organising things like this makes it easier to keep track of everything – at least, that’s what I hope. We use this [quite extensively in the docs](https://forge.fedoraproject.org/org/docs/settings/labels)

Has someone something to announce?

or a comment here?

Hi, I am from Fedora QA team. Could you please take a look at this ticket? https://forge.fedoraproject.org/server/tickets/issues/196 it covers storage interfaces that are currently marked as release-blocking. And we would like to re-evaluate up to the current real use of storage among community.

its about topic 'Re-evaluate the list of release-blocking storage interfaces'

the topic is the next one!

Tracking ticket: link https://forge.fedoraproject.org/server/tickets/issues/196

Max 15 mins

And we have a guest, Petr Sklenar, QWelcome!

And the floor is yours

NOw there are storages listed here: https://fedoraproject.org/wiki/Template:Installation_test_matrix#Storage_devices

There definitely seem some to me that might be not blocking: sas, scsi?, firmware raid?, fcoe, multipath

we would like to know which is currently release blocking. And possible drop some of the current release blocking.

might be we should mark non blocking that is.

My opnion as stated in the server channel was :I think SATA/NVMe, SAS, and HWRaid are what we should block on. (With SAS/HWRAID being optional as it seems like we as a group don't have the hardware to test against those) but SATA/NVMe should be blocking

we very often don't have anyone to test sas... does anyone in the community actually have sas drives and is willing to test?

I would like to ensure, that the commonly build in hardware is working. HW raid is one example, and SAS

As fas as I know, we used to have a text environment with some of those devices.

about sas, there are few machines in beaker, but limited

And arn't all these test automatically?

!hello

mowest: Steve Daley (mowest)

I recal a number of times in recent go/nogo meetings adamw saying that no one has tested sas...

Peter Boy (ServerWG, Docs): the problem is not in automated tests but in ability to get access to hardware

All the server machines we bought recently (well, mostly IBM/Lenovo) had SAS drives an build in HW raid.

true, now sas + FCoE is not tested, as no hw around

we have some older machines in fedora infra that are sas... but all the new ones moved to nvme.

OK, if there is no HW around, we can't test. 😙

I'm not sure how to narrow the list. :) Perhaps we propose which ones are blocking/not in the ticket? or discuss each one in turn?

I would say the blocking be those that we have hardware to test. If some others could be blocking, then someone has to provide hardware access...

might be good to know what ones quality has available to test too?

Probably we agree that we need: NVMe SATA, VirtIO

And swe have equipment for those.

I think nvme, virtio, raid (if we have it) should all be blocking.

available for automation is now : NVMe , SATA , VirtIO, Software RAID, iSCSI

yeah

And we may agree, wie don't need blocking: PARA SCSI firmware RAID

Petr's list for blocking works for me, and Peter's list for non-blocking also works for me

FCoE, SAS, Hardware RAID : we havent access in our lab or via beaker. So its not automated now.

So we need to disciuss: HW raid, iSCSI, FCOE Mulipath

hw raid is pretty varied... there's a lot of different ones out there...

fcoe and multipath aren't probibly something many community members have...

well, but is it probably a usage, we aim at with server?

> fcoe and multipath aren't probibly something many community members have...

sure, and we can say 'please test it and report bugs' but we shouldn't block on it... I don't think...

multipath : currently not blocking: there is test scenario with one fake serial number, but anaconda [tracebacks](https://bugzilla.redhat.com/show_bug.cgi?id=2469006) with this scenario.

fcoe: now way to test :(

proposed !agreed WG agrees to see asblocking: NVMe SATA, VirtIO and as non blocking: PATA SCSI, firmware RAID

Let's stop a moment and check, it we agree about the following proposal

+1

ack

good

+1

+1

+1

+1

OK, I see: +4 by WGmembers, +2 by non-WG members, 0 .-0

correction +5 WG members. so It is dedided.

Then we have some devices we can't test due to lack of equipment: FCOe, Multipath

Therefore:

proposed: !agreed WG will waive the blocking status or FCOe and Multipath as long as there is no test equipment available

+1

What abot this

+1

+1

+1

sure...

+1

+1

OK, so we have 5 WG+ 1nWG+ / 0 /0-

So it is decided.

So we need to discuss: iSCSI, HW Raid,

Do I miss something?

iscsi can be tested, I think we should keep it blocking... there's a lot of folks that used it. hw raid is a lot more difficult...

iSCSI - is it the currently Final blocking - and there is automation for it. HW RAID - we havent tool which woould pick raid+two disks.

HW RAID - its doable in beaker but long manual search + test

OK proposed: !agreed WG agrees to keep the blocking status for iSCSI.

yeah, and like I said theres a lot of models of hw raid...

+1

+1

?? comments about ISCSI

+1

+1

+1

OK, 3+ WG, 2+ nWG / none 0 / no objection.

So it is decided.

Now HW raid is left. I propose, Discussion in ticket and Server room. We have to go to the next topic!!!!!!!

sure, I will collect what we discussed in the ticket. Thanks

OK, let's move on

Tracking ticket: link https://forge.fedoraproject.org/server/tickets/issues/126

ax. 15 mins

the current faviorite are online-inst/offline-inst

comments?

no comment +1

I would like to mimic whatever the majority of the editions or spins are doing.

naming things is hard. ;(

sadly, the server group is the only one left with a install / offline / dvd media...

nirik: Yeah, but DVD is hard, too, in another way

I would love it if we strive for as much consistency as possible in the Fedora project between editions and spins. Because naming things is hard.

I want to keep net-install + offline-install

nirik: So the other editions all require online access to install?

yeah, dvd makes little sense anymore...

What's a DVD?

All desktops have live iso.

I understand they do. I thought they would contain all the files, but when you go to press the local install button they did not works! Took me ages to ger the Server DVD recommended

well, there are raw images and live images, but this one is the only one (along with the netinstall) that actually does an install. the rest just copy to the target.

no desktop provides network bases install

well, you can install a desktop live or a arm raw image 'offline'... but the install is just copying the thing. It's not running the installer itself.

@nirik do you advise we should change our install methods?

no, I'm just saying that the naming is hard... to describe this thing in a few words is not easy

We need to keep the offline DVD type install!

nirik: So the only Fedora edition or spin that "installs" is "Server". Would there be advantages for "Server" to move to a "copy type install"?

well, we already have a virt image right? so we have both already...

I think a copy-type-install is not advisable. With server you need a wide range of storage organization.

Fedora-Server-Guest-Generic-44-1.7.x86_64.qcow2

it's a lot less flexable.

Once again, I'm for streamlining to be in line with other editions and spins, unless there is a reason why "Fedora Server" needs to be the Unicorn. Perhaps to install on some server hardware this is a necessity.

And with the KVM image, we are open to adjust storage organizuation in various ways. That's possible with disk files, but not with hardware disks.

I believe the DVD title conveys that all the files need for install are there. Hence the 'offline' retitle is to convey the same.

offline-install seems okish...

I good with "offline-install" if for some reason we need to have this option, and a straight "copy to disk" method can't be used.

Proposal: let's vote on ticket about online-install / offline-install (or shorted to inst, whatever releng sees fit). And dissuss a change of install methods independent from this.

+1

I guess, changeing the inst method is a longer, and I'm quite content with what we have, It is very efficient. And. we need to focus more one WPE inst,too

+1 for my proposal 😀

+1

+1 "online-install / offline-install"

+1

OK, all WG and all nWG positiv, zere undec 0 negative.

OK, very shortly next one

We have 2 minutes left, I think this needs to move to next week top of agenda.

I think, what we can decide in the remaining time is whether we want to create a separate repo.

Okay, what is the disadvantage to a separate repo?

Would someone like to discuss this ?

I see no disadvantage.

For organization sake it seems to be a good idea.

I've not followed this too much, I am not sure what advantages another repo has, but hard to say without actually haven't read up the proposals.

Kiwi with the kiwi files, seperate repo for reat3ed stuff, tickets repo for tickets.

Seperate repos, all under Server WG would be a good idea to keep things organised.

We would need it for kiwi files during development, docu about our work, docs beginners guide, tickets otherwiese we mightg flood our ticket repo

OK, anyone with objections? Otherwise I would note that we agreed and create the repo.

Okay, I'm for a separate repo it seems to be preferable for most of the WG.

3

2

+1

1

+1

1

So, we are overdue now. Nevertheless not to keep it always below the desk:

Anything here?

Nothing we cant chat in channel about

OK, so thanks for coming! See you next week again.