Currently openQA tests use a BIOS VM for testing Cloud Base images (looks like just the qcow2 image is tested, which is OK).
Fedora 35 Cloud images will be created as hybrid BIOS and UEFI as a result of the Cloud Hybrid Boot feature.
We need to figure out how to 👋 duplicate the test, and modify the copy to do tests in a UEFI VM, and use the same image for both tests. And do this for both aarch64 and x86_64.
This will be needed once the following are merged:
cc: @chrismurphy, @davdunc, @dcavalca, @dustymabe, @salimma
(Originally from fedora-qa#677)
As of Fedora-Rawhide-20210706.n.0, cloud images are now created in a hybrid setup, so we need this to ensure they stay working.
Fedora-Rawhide-20210706.n.0
FYI, the only change I had to do in testcloud to support the UEFI images was to add:
<loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader>
into the <os> block in libvirt xml definition template.
Disclaimer: this was tested with images produced by imagefactory some time ago, I have to verify it works with the hybrid setup.
In theory this is very easy to do, but there's one problem - doing it only for Rawhide and not the nightly builds is actually very awkward due to boring details of how openQA scheduling works.
I notice the Cloud nightlies haven't been run for a week, though. Did we cut them off on purpose?
No, we didn't. ☹️
So, the nightly Cloud composes are back. I'm going to try and see if I can set things up to have the tests only run on Rawhide. I'm honestly not sure if it'll do anything weird. I vaguely recall that the issue we had last time we tried to do something like this may be fixed or fixable, but I've gotta try it and see.
OK, https://pagure.io/fedora-qa/os-autoinst-distri-fedora/pull-request/244 should do the trick here, I hope.
Metadata Update from @adamwill: - Issue assigned to adamwill
Metadata Update from @adamwill: - Issue priority set to: High (was: Normal) - Issue tagged with: improvetest
OK, this is merged and deployed to production and seems to work fine.
Note, when F35 branches we'll need to do a follow-up to implement the same config for F35, and actually again when F36 branches. We can only drop the messiness when F34 goes EOL (or we stop building Cloud nightlies for it).
In fact, thinking about it, it might make sense to reverse the logic here and have * be the UEFI approach, then create 33 and 34 profiles that are the BIOS approach. It's slightly heavier right now, but it needs no future modification except to drop the 33 and 34 profiles once they're no longer needed. I guess I might do that Monday.
*
33
34
Metadata Update from @adamwill: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.