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
1 year, 6 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
1 year, 6 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
1 year, 6 months
Ongoing Fedora website revamp - FEEDBACK needed!
by Peter Boy
After a longer time of preparations the work on the website-revamp is starting now. The first session is Wednesday 27.
In a first step will rebuild the Fedora landing page (fedoraproject.org) and the download page (getfedora.org).
See: https://fedoraproject.org/wiki/Websites/Fedora_Website_Revamp
Currently the Fedora landing page is simple a redirect on the download page. In the future the landing page will be the main page with central information about Fedora and a download link to the download page.
For the design and content of the main page Máirín Duffy made a proposal.
https://discussion.fedoraproject.org/t/a-new-conceptual-model-for-fedora/...
Her proposal is "meant to represent 'the story' of Fedora and how you would use it, and serve as a model from which we will build the narrative for Fedora and its web presence.“
In this model Fedora is
- either a desktop user using Silverblue
- or a Web/App Developer using local container based development or Fedora CoreOs remotely,
- or an IoT Developer using IoT device
IMHO that story is a bit short. Nevertheless, I need feedback what members of or working group are expecting from the central Fedora website and the Download page.
1 year, 7 months
dnf upgrade for Fedora Server 34 ->35 failed
by Peter Boy
I just tried to upgrade one of my test boxes F34 to F35 using dnf system-upgrade download --refresh --releasever=35
It failed at transaction test:
/usr/libexec/osbuild-composer/dnf-json (from Installation of) osbuild-composer-core-31-1.fc35.x86_64 ( collides with file from package) osbuild-composer-dnf-json-36-1.fc34.x86_64
(the message here was localised in German, my translation here)
On 2 other test boxes the upgrade completed without error (one without any additions to the basic install and the other with just postgresql installed).
The test box was basic install an lvm virtualisation.
Did someone else tested an update of Server with kvm installed?
And what is the way to get around that issue?
Best
Peter
1 year, 7 months
update F34 - f35 postgresql module issue
by Peter Boy
I just tested the dnf upgrade procedure on one of our standby backup systems which happens to have the F34 postgresql module version 9.6 installed.
The module was overwritten with version 13 without warning. Given the data incompatibility, this is a very unattractive practice. As far as I remember, one could rely on the fact that with an upgrade the respective module was updated in the installed version.
Fedora 35 comes obviously without Postgres module 9.6. Unfortunately, the release change set doesn’t mention that. We need a clear indication and warning of this.
Peter
1 year, 7 months
Python and PHP packages during update to F35
by Łukasz Posadowski
Hi.
Did any of You had dependency problems while updating F34 to F35? It
happens sometimes with Python, Perl, or PHP packages. Today it were:
php-pecl-msgpack php-pecl-memcached php-pecl-redis5 php-pecl-apcu php-
pecl-imagick php-pecl-igbinary php-common php-pdo php-cli php-fpm php-
json php-mbstring php-opcache php-sodium php-xml php-intl php php-
mysqlnd php-bcmath php-gd php-gmp php-process php-pecl-zip php-fedora-
autoloader php-pear
and
certbot fail2ban fail2ban-firewalld fail2ban-sendmail fail2ban-server
fail2ban-systemd python3-acme python3-certbot python3-certbot-apache
python3-josepy python3-ndg_httpsclient python3-pyOpenSSL python3-
pyrfc3339 python3-pytz python3-service-identity python3-twisted+tls
I had to reinstall those to fully upgrade system to 35 branch, which
involved rewrite of php.ini file.
The best part is: Fedora never broke for me after partial update, even
it Perl and PHP remained behind from N-1 release. It reboots like
nothing happened, sometimes with minor quirks on the Gnome desktop.
--
Łukasz Posadowski
1 year, 7 months
Fedora 35 status and testing needed
by Adam Williamson
Hi folks! Just wanted to give an update on Fedora 35 status and beg for
testing :D
We are now down to either one or two blocker bugs. They are in quite
specific areas so the fixes will not be hugely impactful to anything
else. I'm hoping to be able to run an RC compose later today (Tuesday).
However, we're also only 2 days from go/no-go.
Given this, it'd be super helpful if people could help get the
validation tests run on the current nominated nightly compose. We don't
need to wait for an RC to run most tests; for the more complicated or
trickier tests, we can run them now against a nightly and the results
can be counted so long as nothing relevant changes in the RC.
I've just manually nominated the most recent compose (20211018.n.0) for
testing; it won't have the fixes currently in updates-testing (mainly
for plasma-discover), so take that into account. You can see the
summary page (which shows results from all individual pages) here:
https://fedoraproject.org/wiki/Test_Results:Current_Summary
you can enter results by editing individual sections from that page
(the wiki will automagically edit the correct individual page), or by
using the relval tool - just 'dnf install relval' then 'relval report-
results'.
You can look for tests that really need to be run here:
https://openqa.fedoraproject.org/testcase_stats/35/
each of the pages there shows a sort of 'over time view' of the test
cases of that type, showing when it was most recently run and a little
chart view that illustrates which composes the test has been run on and
what the results were (green for pass, orange for warn, red for
failed). Look out for tests that have release level 'Basic', 'Beta' or
'Final' and which have not been run recently or at all; these are the
ones to focus on. For instance, at
https://openqa.fedoraproject.org/testcase_stats/35/Desktop.html we can
see that several of the desktop tests have not yet been run on aarch64;
it'd be great if anyone with an aarch64 system capable of running
Workstation could run those tests and add the results.
Thanks everyone!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1 year, 7 months
