Meeting started at 2026-09-23 17:00:06 UTC

The Meeting name is 'fedora-server '

!group members server-wg

Members of server-wg: Alexander Bokovoy, Adam Williamson, Paul Maconi, Brett Weir, Emmanuel Seyman, Rowan Puttergill, jwhimpel, Kevin Fenzi, korora (@korora:fedora.im, @korora1981:matrix.org), mowest, ngompa (@conan_kudo:matrix.org, @ngompa:fedora.im, @pharaoh_atem:opensuse.org, @ngompa:kde.org, @ngompa:almalinux.im), Peter Boy, Stephen Gallagher

!hello

Emmanuel Seyman: Emmanuel Seyman (eseyman) - he / him / his

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

!hi

Ro: Rowan Puttergill (goroboro) - he / him / his

!hi

John Himpel: John Himpel (jwhimpel)

Well as I see nirik is lurking so we meet our quorum. We should starft and check, how far we get.

!hi

Paul Maconi (Aggraxis): Paul Maconi (aggraxis) - he / him / his

As of our Matrix discussion we came up with the following agenda

!hi

Brett: Brett Weir (brettweir) - he / him / his

I'm at low capacity right now, but trying to follow along

Regarding the action, see the list in our

meetings overview:

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

system partition on KVM guest and arm image.

At least the list is now a bit shorter

Announcements:

Our voting about article titles in the docs section "Postinstallation Custoimizations" has been finisched. Still 3 votes.

2 votes in favour of all one word title

1 vote in favour in a slightly longer, more descriptive titles.

So, the one word alternative has it.

I don't know if that was a good idea. Usually, the author determines the title of their article.

2 articles to our virtualoisation documentation are still awaiting review

Its adding. v irtualization abd creating a VM ffiom disk image

That's it from me.

I agree there needs to be some amount of overall design, but yeah, you can't name a document that hasn't been written yet.

Has someone something to announce?

I suppose I kind of tested the instructions for the virtualization doc on creating a VM from disk image and that seemed to work for me. I mean, I didn't look at it for style or anything. I am happy to try to provide some review there.

That will need to wait until Friday though

So let's continue

Tracking issue: https://forge.fedoraproject.org/server/tickets/issues/203

Tracking issue: https://forge.fedoraproject.org/server/tickets/issues/193 (image issue)

max 10 mins

Finally got around to doing some tests this week

I test all the iso media vor DVD and netboot, and default and RAID partitioning. No issues.

We still have the LVM partition type issue in the KVM image and the aarch64 SBC image.

And we have a non-functional initial-setup in the KVM image. It seems to be in the aarch64 SBC image to, but in the end it works.

And we have a non-functional initial-setup in the KVM image. It seems to be in the aarch64 SBC image too, but in the end it works.

Everything works as expected. There is an update to the ansible package that I will test later tonight

To be fair, I've haven't tested every single feature of Perl 5.44 and Python 3.15...

To wrap tjhis up:

proposed. !info No new issues with the 2026-09-21 Beta image. The already known issues are not yet resolved.

Is this fixed? Or are we accepting that people need to view in graphical mode?

I would like to keep https://forge.fedoraproject.org/server/tickets/projects/701 open until F45 release

I haven't noticed anything crazy yet aside from what's being reported through the blockers conversation.

No, it isn't yet

And we can't assue graphical moide available. Server is non-graphical by design

Anybody boot with thr wrap up above?

OK then:

Tracking project: https://forge.fedoraproject.org/server/tickets/projects/436

Tracking issue: https://forge.fedoraproject.org/server/tickets/issues/194

30 mins

We had a discussion on Matrix. The floor is open.

I'm standing at a motorway in a provisional parking lot. MAy be I have to move, it the police detects me.

It not a regular parking occasion

I submitted a few improvements to the postinstall role. I think that is just extra to the items here.

Thank you for that, Ro

@Ro++

So we've agreed to furnish a turnkey solution that allows our users to use Ansible whilst hiding the complexity of setting it up?

I intend to add more, but really this is just fluff. What we need to focus on is wrapping up the collection packaging and then get the other bits in place. I have a comprehensive playbook that a user could just edit... and a default inventory, but I kind of think these should be packaged separately

aggraxis gave a cookie to goroboro. They now have 10 cookies, 10 of which were obtained in the Fedora 44 release cycle

I will attempt to try the postinstall role on a clean aarch64 on Thursday or Friday

Yes, I think so.

I set up a galaxy publishing pipeline and I'm trying to cross off remaining issues to release the collection.

I need to decide where to put the playbook... and inventory file. I was thinking another repo, because we could include a wrapper script that hides the ansible complexity. @Brett

I need to decide where to put the playbook... and inventory file. I was thinking another repo, because we could include a wrapper script that hides the ansible complexity. @Brett and I discussed this in channel

I think we should clearly decide abd then avt upon:

> So we've agreed to furnish a turnkey solution that allows our users to use Ansible whilst hiding the complexity of setting it up?

I think we should clearly decide abd then act upon:

> So we've agreed to furnish a turnkey solution that allows our users to use Ansible whilst hiding the complexity of setting it up?

When did we do this? Did we do this for all our recommended services or just Ansible?

I need to decide where to put the playbook... and inventory file. I was thinking another repo, because we could include a wrapper script that hides the ansible complexity. @Brett discussed this in channel

Yeah, that was what we discussed. I can create a repository and set it up if you like to start.

Has anyone else taken the time to review https://redhat-cop.github.io/automation-good-practices/#_where_to_get_and_maintain_this_document ? I think it does a good job of describing some reasonable best practices? I would like to apply these practices to our postinstall role.

Until now we do this with all our services

Until now we do this with all our services, I think

Just point me at a repo and I will start dumping stuff there.

Okay, this was the idea we discussed a couple days ago, let me write up an explain.

There are some chicken-before-egg things... like it would be nice to have the collection in place before we start writing and solving around the wrapper thing.

We'd have a main collection for kind of nuts and bolts stuff, potentially core service roles like NFS, SSH, etc. then add other collections maybe for things like jellyfin and what not.

but the key part is a separate management project.

This could take a few forms, but I think it'll target localhost with an inventory file, and be drivable with a little purpose-built CLI that hides the gory details of running Ansible.

separate management would be a package that pulled in all the dependencies and would give you the template playbooks etc to begin with. But we can write a CLI for it

the management would be the turnkey bit :)

linux-system-roles alreadys handles a number of core services

Yeah, the starting point would be just having a template project with variables to set, and perhaps a systemd unit or some other unit that re-runs Ansible when it detects changes (or systemd daemon-reload and be done with it for now)

So the end user has one or more configs to twiddle, doesn't write their own playbook, and mostly turns on and off pre-packaged single-node playbooks.

Okay, so the first step is to publish the colllection

So our collections themselves are not the primary interface for this target user. They are the vehicle that make it go, but we're making an easy button opinionated wrapper for single node deployments by "typical" users

Yeah, and I'm trying to drive that over the finish line

But not necessarly single node. If you have a separate controle node, youm man maintain multiple servers

That's possible, but the default will be the current system

I've got everything set up for the collection to publish to galaxy. We just need to pick the final name. `fedoraserver.general` is my target for the first collection that contains `postinstall`. Is that good?

To handle other systems, the user will need to edit the inventory... again potentially scriptable... but if different playbooks for different hosts... we need to design and that starts getting complex

Then I need to sit down with Peter Boy (ServerWG, Docs) and enable CI.

Let's go with general

Only the namespace name cannot be changed

And once published, I can set up a specfile and publish to Copr, or enlist Emmanuel Seyman's help with getting into mainline Fedora, haha, since I've never done it before.

I do plan to package the wildfly collection this week. We can do the same to our general collection

but we need a release on Ansible Galaxy first

And we'll publish a package for the management project thing as well.

Okay, excellent. I'll have the Galaxy stuff up shortly after CI is enabled on the repo.

I can package a pre-release...

What do we plan to implement in the CI/CD? Just curious as I've never used that before with ansible.

Enabling CI is quick. Emmanuel Seyman if you have access, you can do it do, or I can create a new repo and move the code there to give myself access to do it

The CI/CD is already implemented. It's just not enabled in the repository settings. It publishes to Galaxy

aggraxis gave a cookie to eseyman. They now have 24 cookies, 4 of which were obtained in the Fedora 44 release cycle

I have too much to do right now...

Brett: Thx for the explaination

Knock knock. The police are politely but firmly asking me to clear my makeshift parking space and continue my journey on the motorway and past the roadworks. They say my spot is too dangerous for me,

so I have to set off now before I get a ticket.

Please remember to wrap things up at the end.

Perhaps I’ll find a proper parking space before the end of our meeting.

And let's meet Friday again!

I have to go!

Emmanuel Seyman: I'll chase down Peter Boy (ServerWG, Docs) or figure out some other way to get it going

See you Friday, Peter Boy (ServerWG, Docs)

Did anyone else have the meeting script for today?

Was the ansible thing the last topic to discuss?

Will the Friday get-together be at 1700 UTC?

Yes... pretty much afaik

I think we are mostly at a point where we can probably sum up and then close

yeah, I think so. My next meeting start anyway. 🫠

There's an open floor topic at the end of every meeting

aggraxis gave a cookie to brettweir. They now have 2 cookies, 2 of which were obtained in the Fedora 44 release cycle

Let's make this quick

I am not sure I can make it on Friday at that time, but will try to be present

Ok, anyone got anything? :)

Not much to report. The CVE-pocalypse is still ongoing

Ro: don't feel bad. I ingest most of these meetings by reading the logs. The timing is in the middle of my workday.

@Brett once we have that repo in place, I will pop the playbook and stuff there. But let's focus on the collection first. Will catch up with everyone in channel and probably more on Friday.

I appreciate everyone's efforts. You folks are amazing. Thank you very much for everything you do!

Okay, I think we can close now