Meeting Minutes 2024

AGREED pboy writes the draft of a document that describes our test strategy.

AGREED: The KVM image will be migrated to KIWI now, the adjustment of the naming will de dealt with later together with the isos.

No decision yet.

In F42, only workstation will benefit from the new Anaconda WEB UI. Before Server can use it, a lot of missing functionality remains to get developed. Workstation will switch to RDP instead of VNC. For remote interactive installation, on the kernel line the parameter inst.vnc is replaced by inst.rdp.

Thanks to Paul Maconi we have our first entry in the "Fedora Server in a virtualized runtime environment" project about installing on Proxmox. Emmanuel will review.

ACTION: Mowest will write a 1st draft of an article about our poll.

NFS 4 is working now, NFS server is running, as well as NFS client. Both need some tweaking.

AGREED Regarding Ansible / NFS we will study and test what we have and continue on meeting in 2 weeks.

AGREED: We discuss this during the next 2-3 weeks on mailing list and try to determine a final plan. One issue to take into account is the lack of test equipment.

Our official current list is here: +!link https://fedoraproject.org/wiki/Server

We have 7 members that never showed even up for the last 2 years. Qur usual procedure is to contact them and ask, what they are planning. And perhaps agree to retreat. And then we should take an initiative to get 1-2 new members. Maybe as part of our upcoming poll.

AGREED: pboy will start to contact dormant members.

After a short reading break postponed to next meeting.

Justin joined us and made an appointment with Mowest to take things further. So we’ll be able to start soon.

AGREED: We finally use the version as now online, i.e. without an "other" option for "How are you using Fedora Server?"

LINK: https://pagure.io/fedora-server/issue/146

With release 42 we will switch to KIWI. ImageFactory is no longer support nor available at all. Current efforts:

LINK https://koji.fedoraproject.org/koji/taskinfo?taskID=125070598

AGREED:Server WG agrees to switch to KIWI (4:0:0)

We agree that manual testing of our installation media and procedures is necessary, and some of this is already included in the test plans. Furthermore, it would be desirable to tailor the test announcement for servers more closely to server issues.

ACTION: pboy will write an updated summary about our release 4 testing and we continue on mailing list and next meeting

Mowest has requested access to the Fedora Limesurvey instance through Gitlab. Furthermore, he created a draft of our survey in a free account of Limesurvey (https://mowest.limesurvey.net/778249?lang=en).

ACTION: pboy will write a summary of the current state of our poll on the mailing list and we continue on mailing list and next meeting.

We still have to test installation on SBCs. Eseyman will take this on.

Mowest had no success yet in pushing the poll through the other Fedora instances. We can’t make any progress in the current state without that.

We decided to use the current version with all inserted modifications and with the shorter of the formulated alternatives on hackmd.io.

Mowest will create a Lime survey version of the discussed draft and reach out to Justin to put the project forward.

We agreed to continue the discussion on the mailing list due to running out of time here. See pboy: Improving our release testing efforts. An attempt to summarize our discussion

The discussion focused on optimizing our approach to release testing. There was agreement on the one hand that the test program should be integrated into the distribution QA, and on the other hand that tests of individual functionalities should be automated. Irrespective of this, there is a need for manual testing, particularly of the (hardware) installation media.

Action: pboy will create a summary on the mailing list, which will be the basis for further discussion.

We finally agreed on 4 goals:

Jwhimpel has finished a first version of the Ansible code including a short documentation. We will discuss this in detail at the next meeting when all members have been able to test it.

Ticket #144 is available for the test. Based on a discussion with adamw, pboy will create a draft test description in the Fedora Server Wiki area. The aim is to automate as much as possible.

Eseyman has created a list of potentially problematic changes, see addendum to the invitation. The list will also be added to the ticket. We will discuss it at the next meeting.

The server roles are basically working. Jwhimpel will add some documentation how to use (and test) it. There are some topics we will have to decide after everyone could use it, e.g. type of mounts. On the client side, we tend to only support and handle Fedora.

We decided to use the same procedure as last time (F40) for now.

ACTION: eseyman will monitor the change list for possible issues which may affect Server

ACTION: pboy will create a tracking issue and copy the table of F 40 as a starting point.

We want to systematize the process and make greater use of the Fedora options, e.g. the results tables that are created for each build.

ACTION: mowest will reach out to AdamW and discuss how we can use the result tables.

Eseyman gave an overview of his impressions and experiences.

One wish that was expressed was to use Fedora as a router, similar to OpenWRT. It was agreed that this is not possible within the framework of Fedora Server, as the requirements for system and data security are too different.

One positive feedback was that Fedora was the slowest moving as well as the most backward compatible, and nevertheless with always up-to-date versions of the server software bits, of the Fedora project. A most welcome characteristic of our goals for Fedora Server Edition.

jwhimpel will start to add topics the the empty doc templates when he completed the first version of the Ansible code.

We considered a number of different topics that were discussed. By and large, our current course in the further development of Fedora Server Edition has proven itself. The most important change will be the implementation of Ansible for our special supported services (previous server roles).

Everyone agrees that getting to know each other and discussing goals and next steps in person was a hugely positive experience and a tremendous motivational boost.Nothing else can replace that. Flock was very, very worthwhile and all the effort was very rewarding. Flock next year is already a positive expectation.

ACTION: eseyman will post his Flock recap to the list.

We decided to do the development in stg branch and add the directory structure there, too.

AGREED: Regarding distribution we prefer the rpm path of action.

ACTION: eseyman review John’s playbooks

We discussed again about the specific goal we want to achive with the Ansible Playbook.

AGREED Server WG agrees to the goal as defined in comment https://pagure.io/fedora-server/issue/138#comment-920322 to issue 138

We want to split the current NFS draft in 2 parts: Installation and Configuration.

ACTION DONE: pboy will create 2 empty docs for installation & configuration to the repo

AGREED to postpone this until we have a working version of the Ansible playbook.

AGREED: We defer the renaming until RelEng has decided about the future Fedora tool set AND has updated the documentation.

ACTION: canceled pboy will file an issue with releng regarding installation media

Eseyman has packed the the robertdebock roles in an rpm : https://eseyman.fedorapeople.org/ansible-robertdebock-roles/. It’s an alternative to the current Fedora standard package. Jwhimple has 4 roles ready, but can’t upload due to permission issues and incomplete Server repo configuration.

ACTION: pboy will add all WG core members as committers to our pagure repo.

We want to split the current NFS draft in 2 parts: Installation and (Basic) Configuration. Jwhimpel will start do add at löeast bullet point to outline the intended information. To support this, pboy will add correspoding empty files. We agreed to document the process using Ansible and by using manually CLI. Whether and how we take Cockpit into account is still to be decided.

ACTION: pboy will create 2 empty docs for installation & configuration to the repo, then everyone can add relevant topics to it and migrate the current integrated doc.

Discussed the specific goal of this work. Agreed to focus on a playbook for commen/default use case and provide hooks to extend to further local use cases.

We agreed to start with a poll and ask users how they use Fedora Server Edition and what they are missing in the first place. Mowest and pboy will work on it.

AGREED: Server WG switches to a weekly meeting

jwhimnpel will provide 2 Ansible roles in about 2 weeks for further discussion and testing.

eseyman and mowest will work on improving the current docs draft.

We discussed the results of a short poll about the documentation part and how to improve the current article. Amoung others we want to split into installation and configuration and in each part describe the manual procedure and the Ansible usage.

We will add a new subdirectory to our repo for Ansible scripts.

Jason will start to elevate Fedora Server VM distribution image to a release requirement as the other Server installation images

AGREED: Server WG agrees that the Fedora Server option has to be removed from the Everything Install medium in the long term.

W’ll pick this up again as soon as we have free resources.

AGREED: WG’s goal is to provide a spin "local or public file server (NFS, Samba, Ansible support)

AGREED: WG’s goal is to improve the use of Fedora Server in a VPS infrastructure and to promote it as a standard offering.

AGREED: Server WG decides to rename the installation media: DVD → offline , netboot → online, KVM → virt, and rawsbc for ARM raw image.

AGREED: Server WG decides on a consistent naming convention according to the scheme: "Fedora-Server-<rel>-<method>-<arch>-<version>.<filetype>"

jwhimpel will check the details of the procedure and report back next meeting.

We will start to discuss and develop NFS service supported by documentation and by Ansible.

The issue is resolved, but but - as Vojtech Trefny, one of ghe maintgainers, put it - "unfortunately not thanks to the changes that I made".

AGREED: Server WG considers the case closed.

AGREED: Server WG considers F40 ready for publication and closes this topic.

AGREED: Regarding our "story" for F40 we stick sich ARM SBC.

See: issue #134

We narrowed the options down to "Fedora Server VM as VPS", "Server Edition as identity server ", and "Server Edition as local or public file server ".

The discussion revealed obvious inconsistencies between the ways of creating our various installation media that have evolved over time. All of this is difficult to deal with in a matrix discussion. Therefore:

AGREED: An additional meeting out of turn on Wednesday, April 10, 17:00 UTC in the Matrix Sever room exclusively to discuss the Review Installation Media topic.

ACTION: pboy will prepare the room and provide a test opportunity.

No additional issues found yet, but not all planned tests have been carried out yet.

It is unclear how and where the test results should be merged on the server test page. Pboy will contact Adam about this.

The online/offline proposal is welcomed, but the overall solution should be presented more clearly.

A decision will be aimed for by mid-May at the latest so that there is sufficient time for implementation.

!link https://bugzilla.redhat.com/show_bug.cgi?id=2247872

The /etc/lvm/devices directory in Fedora-Server-KVM-40_Beta-1.9.x86_64.qcow2 is empty now. So far no check whether First Boot generates a suitable entry.

INFO update: Beta 1.10 contains a devices file in both server images (KVM and aarch64 SBC). So the issue is not resolved yet.

Action: cooltshirtguy will monitor and check the aarch64 SBC image, specifically Raspberry Pi.

We have selected items to be tested and allocated work. Details at

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

!info: Unfortunately, no movement on the Apache / httpd configuration layout yet

We are discussing how to equalize the times of the meetings of the Server WG and the Epel Team to enable everyone to participate in both. To be continued on the mailing list.

An initial analysis has revealed a number of warning messages about comps files not being found. Details in:

Link: https://pagure.io/pungi-fedora/blob/main/f/variants-fedora.xml#_46

Link: https://pagure.io/fedora-server/issue/130

Agreed: Sever WG will check the current compose groups in issues on fedora-server repo.

The arm-image-installer script is fixed.

The LVM configuration issue is still open.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2247872#c19

This issue is not accepted as release blocker. So it can happen that we release a kind of crap image for the 2nd time in a row.

But LVM group seems to be working hard on it.

Eseyman generated a list of items requiring our attention

Link: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/message/CNH57V7LT4GMQN676XFDJWQ6U46BGDMK/

Agreed: Server WG will continue to discuss this topic on mailing list

Nothing to discuss today.

We are trying here for more then 2 years for now without a lot or results. At Fosdem I met Tomáš, who is very experienced in release engineering (to put it a bit understated) and who has offered to help us with this. This is a great opportunity for Fedora Server Edition.

After an initial discussion about necessary and desired changes, we agreed that Tomáš would further analyze the current configuration files and compile them in a blog or on the server list.

The various server installation media are (still) named very differently. But it is now too late for a change to Release 40.

Agreed: We further discuss naming convention on mailing list and aim to make a final decision in 4 weeks latest. And then it is up to releng to find a workable timeframe. There is no urgency.

The issue is currently not resolved.

A proper resolution will involve an anaconda fix as well as a fix in arm-image-installer. We will continue to work on it.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2258764

Cloud Sig will stop to maintain ImageFactory. For F41 we have to select another tool for building the non-iso images. Probable choices are Lorax, KIWI, or OSBuild, depending on what is supported in pungi and what artifacts are supported by the different tools.

Neil would support a move to Kiwi if we decide to do so. We want to make a final decision once releng has decided on available and supported options.

We finally got information about the reasons for the changes in LVM default configuration and proper ways to resolve the ARM SBC installation issue.

In short we should retain the current default LVM configuration which includes a system.devices file and adjust the arm-image-installer script und our documentation.

We have set up a list of manually "smoke tests". We now need working group members or other interested parties to take over some of the tests and enter their FAS names in the corresponding column.

We will switch our meetings from IRC to Matrix starting February 21, provided we can make the necessary organizational arrangements in time.

Currently the default LVM configuration results in vgscan and vgchange not inspecting new devices that are not listed in /etc/lvm/devices/system.devices. A follow-up to this is also the error when creating aarch64 SBC filesystem images.

There was neither a change proposal nor a release notes entry for the configuration change, nor any announcement. Accordingly, it is also not known why the change was made.

ACTION: eseyman will try to contact the maintainers and get information why the change was made.

We will continue discussion next meeting

We will continue discussion next meeting

Currently the default LVM configuration results in vgscan and vgchange not inspecting new devices that are not listed in /etc/lvm/devices/system.devices. A follow-up to this is also the error when creating aarch64 SBC filesystem images.

There was neither a change proposal nor a release notes entry for the configuration change, nor any announcement. Accordingly, it is also not known why the change was made.

ACTION: eseyman will try to contact the maintainers and get information why the change was made.

We will continue discussion next meeting