Meeting started at 2025-08-20 17:00:04 UTC

The Meeting name is 'fedora-server '

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

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

!hi

Jocelyn Gould (korora) - she / her / hers

!hi

Paul Maconi (aggraxis) - he / him / his

!hello

Steve Daley (mowest)

Welcome everybody!

!hello

Emmanuel Seyman (eseyman) - he / him / his

I think, we are already ready to start.

Anything to add / remove /change / ... ??

There is one question in Fedora Discussion that I spotted last night...

Which one?

https://discussion.fedoraproject.org/t/request-additional-packages-to-be-included-on-dvd/162524

Yes, OK I remember the mail.

Let's add this after topic 2 as 2a . OK?

Sure

OK. Let's start.

Again, Regarding the action, nothing new. See

Kind of announcement:

I had a bit of an interesting discussion with our new project leader:

Our new FPL seems not much familiar with the concept of Editions and the "management strategie" that stands beind such a move (focus and intensity to grow ) I expect we have some discussion to do.

I hope I have met our position good enough.

Maybe, a short look at the discussion?

I get what he's saying

This seems to be a quibble over words more than anything else...

He can't establish a documentation link to the requirements

I'm sure intent existed, but it's not spelled out in writing somewhere, or the requisite document is lost in the shuffle between platform migrations, etc.

I think (or fear) it not just a quibble over words. It's about strategy

Much is not in separate documents but was part of tons of discussion. That might be a problem.

Ok well... I'm not even entirely sure that was informative other than there seems to be a disconnect.

At the end it may be about ressources.

And that may become a problem.

Anyway, let's see how this evolves.

Anything else to discuss here?

No, I just saw the original question that sparked this fire.

"Does anybody know if there will be a regular immutable version of Fedora Server? I mean with bootc and composefs, but without Butane and Ignotion. So not CoreOS, but a ‘regular’ immutable version of Fedora Server."

Essentially, he's asking for a Fedora flavor of RHEL Image Mode.

Yeah, we discussed that a lot of time ago.

I have some sympathy for this idea. But can we do it? Do we have the ressources to create (and maintain) a boot image?

why would we do it?

Yeah I'm back to why?

coreos already exists

Another idea of mine: To tailor our planned home spin that way.

in what practical way is an immutable server different from coreos?

oh, i see above, but still, it's a fine slice

I always thought this would happen as part of CoreOS, TBH

adamw: Not completely immutable, more like silverblue, just an immutable core.

I'm considering the Fedora Server audience. Largest segment is homelab, and I'm not seeing the reason at this point to create a bootc / immutable version of Fedora server. I can see the wisdom in experimenting with image based bootc VM's or Containers.

I also agree with adamw who mentioned CoreOS, why have a second atomic version of server.

Server versions should be rock-sol;id and tested, with large user bases and support. Maybe wait until the immuntable tech has become the norm (if it happens).

I will refer you to a RHEL Image Mode article. It's clearly important enough that Red Hat is marketing the concept as a product.

https://developers.redhat.com/articles/2024/11/05/image-mode-rhel-4-key-use-cases-streamlining-your-os

i don't understand the distinction you're drawing

sb and coreos are immutable in the same sense

But even as a customer, I'm struggling to get my head around why or how I'd implement it, especially in an offline environment.

in both cases the core os is immutable and you are supposed to deploy things on top of it using a different system (containers, flatpak or whatever)

It's hard enough dealing with CoreOS offline.

adamw: As fas as I got it, you can install rpm packages in silverblue, or did I get it wrong?

you got it wrong

well, you can overlay packages on any rpm-ostree base (including both coreos and silverblue), but it's the Wrong Way(tm) to do immutable and more of a hack

it basically creates a new immutable base with the package you wanted overlaid and that has to get reconstructed every time you update the 'real' base

I think everyone is agreed that a bootc / immutable version of Fedora Server is not on the roadmap any time soon. Steer such questions to encourage them to explore Fedora CoreOS

adamw: That's not an attractive perspective :-)

or IoT if you want to deploy with anaconda, i guess

Well. I'm a little surprised now. I always thought I was the only one in the world who found classic, package-based servers very useful.

i'm pretty sure you aren't :P

Same

OK, for the protocoll: We agree to keep server as a package based system for the foreseeable future and don't intend to start an alternative planning any time soon.

I manage entire fleets of package-based servers, and it works just fine, especially since things like package management, mirroring, and anaconda's flexibility allow me to do all of that without being connected to the internet. I just have to buy enough licenses to cover my usage.

Honestly? If anyone was going to do it, it'd be whatever SIG owns bootc.

Paul Maconi (Aggraxis): Same for me at out university.

https://docs.fedoraproject.org/en-US/bootc/ There are docs, so there's definitely a SIG at work.

Paul Maconi (Aggraxis) that's not really the idea, the idea is that it should work this way. the bootc dev team doesn't maintain coreos and iot and silverblue and so on. but 'atomic server' just isn't a great fit, especially when coreos exists.

Paul Maconi (Aggraxis) that's not really the idea, the idea is that it should work this way (SIGs for specific areas maintain immutable builds for those areas). the bootc dev team doesn't maintain coreos and iot and silverblue and so on. but 'atomic server' just isn't a great fit, especially when coreos exists.

I get what you mean.

OK,then:

Any objections to switch to next topic?

Do it :-)

No. Let's go

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

I did testing ob barfe metal installation on UEFI of default install and SW Raid advanced gui

It basically works, but the advanced configuration UI is kind of "flat" and hard to work on (visually).

Still haven't gotten around to testing F43...

I'll enter it to the test matrix later

Emmanuel Seyman: Thanks for the list of the special topics.

I picked some of the items.

Anything to add? Anyone else some test results?

OK, let's move to 2.a

In the discussion post, I didn't see a list of packages that were desired.

Emmanuel Seyman: is this an old post or a new one? We have such an request for about 2 years now and there is an issue in the repo

This is new (it's two days old)

It showed up yesterday in my RSS feeds

@mowest : you have to read the original post, not the updated one

click the orange pencil

Where is the original post?

OK

https://discussion.fedoraproject.org/t/request-additional-packages-to-be-included-on-dvd/162524/2

steppybug wants ansible-core and dnsconfd added to the server iso

Now I don't know anything about dnsconfd...

Well, ansible-core seems useful given our ansible projects.

and ansible-core is the type of package that you will install on only one or two servers so including it in the iso might be overkill

but the rpm isn't that big

That's not necessarily true

maybe these are for gapped servers

If you weren't using a centrally-managed ansible, having it on your hosts post-install would be useful for local execution

Emmanuel Seyman: Yeah, I remeber , agentless :-)

Even with my disconnected environments, we still use the automation controller, so the ask is a little puzzling.

I would guess that most homelab people are not using ansible with a centrally managed server. They are likely using "ansible-pull" I believe it is called to pull in their playbooks to run localing on their fresh server

That's a pretty commonly used scenario. yes.

It isn't unique to Fedora users, either. Similar functionality is outlined for Ubuntu Server, for example.

So for the majority of our crowd, having ansible-core on the machine so nothing new needs to be added to kick off an ansible playbook sounds like a worthy include.

I'm going to require some stats to believe that this is a common thing

We could do another survey. :)

I do it from time to time but I consider it a hack

Interfaces for Ansible-pull support are baked into cloud-init, which is something Fedora Server can have post-install, but doesn't come with out of the box. Fedora Cloud does have cloud-init baked in.

I spend a lot of time in the homelab discussions most of which focus on Debian and Ubuntu which are used even more than Fedora Server in the homelab, and the ansible-pull is the recommended way to kick off a playbook. But I'm sure that enterprise or business installs would probably run a central managed server for this.

Size of package*Update Frequency*User Numbers, compared to free space on a dvd... (if its really not an impact then a small user base is okay and no survey needed)

I tend to run the few playbooks that I do have from my workstation class machines

Size of package x Update Frequency x User Numbers, compared to free space on a dvd... (if its really not an impact then a small user base is okay and no survey needed)

My main problem: Before we can even think about changing the installation media, we first need to get ourselves up to speed so that we can change our media. We still have a deficit here. This is a project that I have been pursuing with Keven for a long time, but especially since Flock this year. But we both have enough other things to do. So it will take some time

And in the meantime, we have enough to do with improving the current situation, e.g. our Ansible projects.

TLDR, one of our users want to include more packages in the server iso

Regardless of what we decide, we simply do not have time for this in the coming months.

It's sad, but that's the way it is.

understood

And things like working NFS, web, etc. seem more urgent to me.

OK, so we keep this on our long term agenda, but postpone for now?

dnsconfd would have a possible conflict, we would have to do some research how including that would impact Fedora Server's current configuration. From its Github read.me "Current version uses systemd-resolved plugin from Network Manager. Therefore it cannot run together with systemd-resolved.service at the same time."

Let's move on, shall we ?

This strongly suggests that this should not be pursued further at present.

The end user could also look into how to build a custom image with Kiwi

Let's move on, shall we?

Yes, letÄ's move on

He's already got a workabout

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

We already had a short discussion. Most urgend is the publication of the SW Raid extended doku.

And in addition, we have to decide about the topic of reducing the blocking bug list.

proposed: !agreed We publish the extended SW Raid doku now as is (adding F42 in meta data). Further refinement probably after F43 release.

Yes!

Yes

Yes

proposal !agreed We limit the blocking bug property for BiosBoot to the default installation and the installation of a 2 disk SW raid1 installation useiing the advanced blivet GUI

OK, part 1

What about the second proposal!

Does Anaconda default install automatically create a SW raid1 when there is a separate disk in the computer?

mowest: No, you have to do it manually

I guess I would be more in favor of dropping the last part then, because it will be easier to test for a bug if we limit ourselves to the Anaconda default install.

There is a discussion about this here

The SW raid 1 is very important for installing an rented hardware in various data center

They are still bond to biosboot because of their management infrastructure.

We are running out of time, but we need a decision here, if possible.

So any objections regarding the second proposal?

None

Well obviously no objection

!agreed We agree to limit the blocking bug property for BiosBoot to the default installation and the installation of a 2 disk SW raid1 installation useing the advanced blivet GUI

Well, we are over our time schedule.

I propose, we start next meeting with the topics 4 and 5 ?

Have a good night in Europe.

Yeah, thanks!

Sounds good on the next meeting propsal

Yes, I agree

OK, so let's close now.