Open Source Experience
by Emmanuel Seyman
Hello, all.
FYI, I'll be at the Open Source Experience event in Paris, France over
the next two days.
https://www.opensource-experience.com/en/
I'm hoping to be able to talk to the people at the Centreon and Itop
booths about supporting Fedora Server as a platform.
Emmanuel
2 years, 5 months
Short info about last IRC meeting (2021-11-17)
by Peter Boy
Again, for everyone's convenience, a brief summary of our IRC meeting right here
For greater details see meetbot
Summary: https://meetbot.fedoraproject.org/fedora-meeting/2021-11-17/fedora-server...
Full log: https://meetbot.fedoraproject.org/fedora-meeting/2021-11-17/fedora-server...
Topics discussed:
=== Moving Wiki Pages to docs.fedoraproject.org ===
#link: https://pagure.io/fedora-server/issue/52
#agreed: Server WG decides to initiate the move from Wiki to docs.fedoraproject.org
#action: pboy and mowest will initiate the necessary measures
=== Synchronize Server full install and net install iso images ===
#link: https://pagure.io/fedora-server/issue/32
This is a long running issue. Some of us have tried solution steps. But despite everything, the topic remained unfinished until now.
#action: pboyHB and davdunc will bring the issue forward and report in about 4 weeks
=== Revisiting "Software Selection" options in Server Installation ===
#link: https://pagure.io/fedora-server/issue/51
We will discuss this an on mailing list in greater details.
=== Fedora Server Edition default editor ===
#link https://pagure.io/fedora-server/issue/55
There was a lively discussion in which 2 views became apparent
- vim is the tool of choice for system administration
- It is a value in itself to follow the Fedora default design and the skilled system administrator will switch over or overwrite via kickstart file.
A possible way to combine both would be to make the choice of the default editor customizable via optional installation items (current right column in software selection menu). This are to be updated anyway.
==== Schedule of the next IRC meetings ====
In December we will again have an additional Wednesday, so our 14-day rhythm will get out of sync. And on the first Wednesday in January, experience shows that many will still be on vacation.
Therefore, please note the following schedule for our next meetings:
== December 1, 2021 17:00 UTC
== December 15, 2021 17:00 UTC last one in 2021
== Januar 19, 2022 17:00 UTC first on in 2022
== Fabruar 2, 2022 17:00 UTC
== Februar 16, 2022 17:00 UTC
Followed by a 14-day rhythm and at the end of March the next "rhythm disruption“.
=== Info about upcoming topics ===
(not complete and not exhaustive)
= Our work project 2: Using Ansible to install and configure Wildfly
See: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....
= Our work project 3: Facilitated and improved support for Fedora Server Edition VMs
See: https://pagure.io/fedora-server/issue/53
= Revisiting our release criteria =
As proposed by Stephen Gallagher sometimes ago
= Preparation of a SBC reference list =
As discussed on mailing list
= Revisiting our quality criteria and procedures =
As discussed on mailing list
= Specifying F36 manual test requirements =
As discussed on mailing list
= Adding Upgrade notification (dns-automatic) to install image =
As discussed on mailing list
= Fedora Website Revamp =
Ongoing work, we will need content related to Fedora Server sometime soon.
= Evaluating Fedora Server Working Group =
We have some members who never showed up nor contributed any work. Others have obviously evolved other interests in the meantime. And we have (new) contributors formally not members.
2 years, 5 months
F36/37:- Our Work Project 3: Improved support for Server Edition VMs
- Feedback appreciated
by Peter Boy
On our agenda there is the project "Facilitated and improved support for Fedora Server Edition VMs". Once started as a prospective cooperation with cloud WG, this prospect has bluntly failed.
The question now is how can we easily and efficiently provide a virtualised version of Fedora Server for a bare-metal Fedora Server with virtualisation support installed. This question becomes urgent given the power of current hardware.
Currently there are 4 Options ready to use:
(1)
Usage of Cockpits 'Create VM' which launches Anaconda installation support and guides you through the standard installation process.
You get a perfect duplum of Fedora Server in virtualized form, but at the price of a significant amount of work.
Instead of Cockpit you could use an elaborate invocation of virsh, but the effort will not be less.
That's not exactly the goal of our project.
(2)
Installation of guestfs-tools (f35, libguestfs-tools-c in f34) and use virt-builder to create a partly customized disk image (e.g. root password) that you can import using virsh
You get a disk image file pretty quickly and importing it into KVM is easy and fast as well.
You will not get a duplum of Fedora Server virtualized, contrary to the description in virt-builder. Cockpit is not installed, filesystem is without LVM, many software packages are missing (vim, tar , sshfs, etc), firewall without Fedora Server zone - just to name a few.
The qcow2 image file created by default has a capacity of 10 GiB and also occupies 10 GiB in the file system - so no use of dynamic capability of qcow2 format. The image is generated on an external server and imported as a binary.
With all the effort we put into Fedora to build even the smallest rpm package completely from source on Fedora infrastructure, it seems pretty absurd to use a complete VM binary from a third party source or to rely on an external binary image.
Overall, this is not a suitable solution.
(3)
Usage of mage Builder Tool / Cockpit module
The tool creates an elaborated image file. But in the current implementation it requires almost a similar effort as an Anaconda installation. And as in the case of virt-builder, a binary is imported from an external source.
So it is a similarly limited suitable solution.
(4)
Usage of cloud base image
This solution would be Fedora controlled after all. Importing via virsh is simple and fast. But the result is far from being a duplum of Fedora Server - no firewall, no cockpit, different file system, missing software, just to name a few. And a duplum is explicitly not intended by cloud WG.
Altogether, this option is not a solution either.
= Conclusion =
Unless I have overlooked an adequate tool, our only option is to supply our own image file - similar to what CoreOS does.
We already provide a perfect image file for Arm64 SBC devices - including initial configurability, similar in scope to Anaconda. Could this serve as a template?
Maybe that would be a realistic goal for F36 release?
Feedback and other possible alternatives are very much appreciated.
Best
Peter
2 years, 5 months
Call for agenda items on 2021-11-17 17:00 ==UTC== meeting
by Peter Boy
The meeting is scheduled:
==============================================================
Fedora Server IRC meeting Wednesday, November 17 17:00 ==UTC==
irc.libera.chat #fedora-meeting
==============================================================
According to my notes we have to discuss
== Agenda ==
https://pagure.io/fedora-server/report/Meeting
1. Preparing Fedora Release 36
(a) Synchronize Server full install and net install iso images
https://pagure.io/fedora-server/issue/32
(b) Revisiting "Software Selection" options in Server Installation
https://pagure.io/fedora-server/issue/51
(c) Facilitated and improved support for Fedora Server Edition VMs
https://pagure.io/fedora-server/issue/53
2. Moving Wiki Pages to docs.fedoraproject.org
https://pagure.io/fedora-server/issue/52
Please everyone, provide feedback!! Either here on mailing list or by commenting on the issue. This concerns topics that are considered to be of particular interest / relevance as well as those that should discarded / don’t need a IRC meeting.
=== Other upcoming topics in the books ===
(I’m preparing but *not yet* finished)
= Revisiting our release criteria =
As proposed by Stephen Gallagher sometimes ago
= Preparation of a SBC reference list =
As discussed on mailing list
= Revisiting our quality criteria and procedures =
As discussed on mailing list
= Specifying F36 manual test requirements =
As discussed on mailing list
= Adding Upgrade notification (dns-automatic) to install image =
As discussed on mailing list
= Fedora Website Revamp =
Ongoing work, we will need content related to Fedora Server sometime soon.
= Evaluating Fedora Server Working Group =
We have some members who never showed up nor contributed any work. Others have obviously evolved other interests in the meantime. And we have (new) contributors formally not members.
2 years, 5 months
Server IRC meeting today 17:00 UTC - a gentle reminder/agenda update
by Peter Boy
As a gentle reminder and agenda update:
Our next meeting is scheduled today
==============================================================
Fedora Server IRC meeting Wednesday, November 17 17:00 ==UTC==
irc.libera.chat #fedora-meeting
==============================================================
Please, check your local time using
date -d '2021-11-17 17:00UTC‘
**The end of daylight saving time may have shifted the time used to so far.**
== Updated Agenda ==
https://pagure.io/fedora-server/report/Meeting
1. Preparing Fedora Release 36
(a) Synchronize Server full install and net install iso images
https://pagure.io/fedora-server/issue/32
(b) Revisiting "Software Selection" options in Server Installation
https://pagure.io/fedora-server/issue/51
(c) Fedora Server Edition default editor
https://pagure.io/fedora-server/issue/55
(d) Facilitated and improved support for Fedora Server Edition VMs
https://pagure.io/fedora-server/issue/53
2. Moving Wiki Pages to docs.fedoraproject.org
https://pagure.io/fedora-server/issue/52
3. Work Project 2: Facilitated deployment of key services by combining rpm and Ansible
Prototype implementation: Using Ansible to install and configure Wildfly - Status Report
https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....
(I didn’t manage to create a meeting issue for this so far)
See you later today
Peter
=== Other upcoming topics in the books ===
(I’m preparing but *not yet* finished)
= Revisiting our release criteria =
As proposed by Stephen Gallagher sometimes ago
= Preparation of a SBC reference list = As discussed on mailing list =
Revisiting our quality criteria and procedures
= Revisiting our quality criteria and procedures =
As discussed on mailing list
= Specifying F36 manual test requirements =
As discussed on mailing list
= Adding Upgrade notification (dns-automatic) to install image =
As discussed on mailing list
= Fedora Website Revamp =
Ongoing work, we will need content related to Fedora Server sometime soon.
= Evaluating Fedora Server Working Group =
We have some members who never showed up nor contributed any work. Others have obviously evolved other interests in the meantime. And we have (new) contributors formally not members.
2 years, 5 months
Call for Agenda for next IRC meeting
by Peter Boy
Our next meeting is scheduled for Nov. 3.
Currently, I don't have any agenda topics on the books and there are no open actions.
Upcoming:
* open action on issues #48 and #32 when Fedora 35 is finally released (in charge: Eighth_Doctor)
* further development of documentation (in charge: pboy, copperi)
* plannings for Fedora 36 / 37
* progress with our working plan
Please, everyone check to see if you have a discussion topic for next week's scheduled meeting.
If I don't have a feedback here on the list by Sunday, Oct 31, I propose to cancel the next meeting.
Best
Peter
2 years, 5 months
Issues with libvirt and Fedora 35 - advice required
by Peter Boy
I'm still in the process to update documentation and recommendations of installing libvirt virtualization on Fedora 35 Server.
As discussed some times ago libvirt switsched from monolithic libvirtd to modular archticture resulting in various daemons and sockets.
(a)
Installing on a fresh F35 Server installation I get various disconcerting warnings / error messages
(1)
> Installing : qemu-common-2:6.1.0-9.fc35.x86_64 253/361
> Running Scriptlet: qemu-common-2:6.1.0-9.fc35.x86_64 253/361
> useradd warning: qemu's uid 107 outside of the SYS_UID_MIN 201 and SYS_UID_MAX 999 range.
That's definitely a warning, user qemu is created with UID 107. It's messy, but it works.
(2)
> Running Scriptlet: libvirt-daemon-7.6.0-3.fc35.x86_64 298/361
> Failed to preset unit: Unit file virtlogd-ro.socket does not exist.
> Failed to preset unit: Unit file virtlockdd.socket does not exist.
> Created symlink /etc/systemd/system/sockets.target.wants/virtproxyd.socket → /usr/lib/systemd/system/virtproxyd.socket.
Wondering about that. According to libvirt documentation those are needed. But so far I didn't get any problems.
(3)
> Installing : libvirt-daemon-driver-storage-core-7.6.0-3.fc35.x86_64 299/361
> Installing : libvirt-daemon-driver-network-7.6.0-3.fc35.x86_64 300/361
>
> Running Scriptlet: libvirt-daemon-driver-libxl-7.6.0-3.fc35.x86_64 361/361
> Running Scriptlet: libvirt-daemon-driver-vbox-7.6.0-3.fc35.x86_64 361/361
> Running Scriptlet: libvirt-daemon-driver-storage-7.6.0-3.fc35.x86_64 361/361
> Running Scriptlet: virt-win-reg-1.47.2-2.fc35.noarch 361/361
> Failed to connect to bus: invalid argument
> Failed to connect to bus: invalid argument
Seems to be a general issue with dnf / packaging. The severity/significance is unclear to me.
Has anyone else had these issues?
All of this probably doesn't cause any serious problems, but it is at least very unattractive. Do we want to get this fixed now or postpone it to Fedora 36?
(b)
The current default installation doesn't activate the internal network virbr0 to enable internal protected communication between VMs und host. Instead you have to separately start/configure 1 or may be more 'additional daemons' for the service of 'secondary drivers'. Has anyone already worked with it and gathered experience? At first glance, you only need virtnetworkd and get a similar configuration as before.
On the other hand, it might be advantageous to take the opportunity and switch / recommend (in the documentation) to dispense with the libvirt internal network configuration and configure a virtual bridge right away using NetworkManager and its dnsmasq plugin. Then we would achieve a consistent network management without libvirt interfering, bypassing NetworkManager. I also hope for a better integration of the name resolution by systemd-resolved, which due to the idiosyncrasy of libvirt only works via an auxiliary construction with hooks (but also not smoothly).
What is your opinion about that?
The current still incomplete version of the updated documentation is available at https://docs.stg.fedoraproject.org/en-US/fedora-server/virtualization-ins...
Any hints / comments appreciated.
Best
Peter
2 years, 5 months
How good is the real quality and reliability of our deliverables?
by Peter Boy
We are officially distributing a Fedora Server Edition disk image for ARM, typically used for SBCs. I just tried to install this image on a Radxa Rock Pi 4 and failed miserably. That SBC device is part of the installation procedure provided by the ARM team. With the F34 image I ended up with a black screen, no display, no chance to get the device working in the normal way (I got it to work in tricky detours). With F35 Beta I got a working display, but no network connection. I haven't found a solution for that yet.
And then I remembered F33, where it was discovered by chance (!) at the last minute, that in the x86_64 version Cockpit did not work properly (and probably also in the aarch64 default install version, we didn't and probably couldn’t even check that afterwards). We have not solved the underlying issue for this until today, although the factual reason has been clear for a long time (issue #32).
Similar problems had emerged after the release with the switch to systemd-resolved, where "surprisingly" problems with some server configurations were encountered, especially with elaborate use of KVM virtualization on a server.
These events are clear violations of our release criteria. In principle, a release must be at least successfully installable and basically working.
For me, this brings up a few questions:
(1)
Did any of us actually have Fedora Beta installed on a ARM device (SBC or other) using the image file and on which model?
Or are we just flying blind with that deliverable?
(2)
What about the two aarch64 install iso files that target SBSA hardware? Does anyone have such a beast at hand and tested the isos? Or is that (also) flying blind?
(3)
And what about x86_64 installation? Most of us will be in possession of this hardware. But what about tests? When I started a discussion about testing a year ago, Adam reassured us, release building and testing is heavily automated these days. No need to worry too much about testing it manually ourselves. But did anyone of us at least worry a bit?
I would like to discuss how we can gain some improvement.
Regarding arch architecture, could some kind of cooperation with arm group be beneficial? And what can we offer? Is it testing? Is it documentation? Or something else?
If we want to take SBC devices seriously, perhaps we could identify a few reference systems where we can actually ensure, i.e. test, whether a successful installation and basic functionality is met. If we don't want that, we should not distribute the image file under the Fedora Server Edition branding.
And in terms of our "main" architecture, we should agree on what QA actually expects in terms of non-automated testing and how we want to tackle that in the next round. Based on Adam's comments, we have relied heavily on automation for the last few releases. So it's not clear to me what, for example, the page
https://fedoraproject.org/wiki/Test_Results:Fedora_35_RC_1.2_Server means in detail in terms of work.
Happy Sunday
Peter
2 years, 5 months