This should not be set here; it is set in the 'product' (i.e.
the flavor), so it's set to 'gnome' for Workstation live flavor,
'kde' for KDE live flavor. Setting here overrides that and makes
it always 'gnome', we don't want that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is the magic variable to disable openQA's "cancel whole
cluster on child failure" behaviour that I'm adding in
https://github.com/os-autoinst/openQA/pull/2017 . We want it
set for all parallel parent suites in Fedora.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is using the two tests previously added by
"Test upgrade of FreeIPA server and client deployment"
Signed-off-by: Michel Normand <normand@linux.vnet.ibm.com>
Obviously an installer image may work fine for a BIOS install
but fail for a UEFI install, so we should test it both ways.
This requires the invention of a new (terribly named, but I
couldn't think of anything better...) variable to allow us to
use the 'run test on machine A after test run on machine B'
mechanism without just hardcoding '64bit' as the machine name
in the START_AFTER setting (which would break if we ever wanted
to run update tests on any *other* arch).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a test which builds a netinst image potentially with
the package(s) from the update, and uploads that image. It also
adds a test which runs a default install using that image. This
is intended to check whether the update breaks the creation or
use of install images; particularly this will let us test
anaconda etc. updates. We also update the minimal disk image
name, as we have to make it bigger to accommodate this test,
and making it bigger changes its name - the actual change to
the disk image itself is in createhdds. We also have to redo a
bunch of installer needles for F28 fonts, after I removed them
a month or so back...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Today's Workstation live doesn't boot at all without enforcing=0.
We *still* want to see how subsequent tests run, so let's work
around this for now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is known to not work at present as it's not implemented in
DNF yet; failing on it every day isn't proving much. Once it's
implemented (expected by end Jan) we can turn it back on again.
See https://bugzilla.redhat.com/show_bug.cgi?id=1616167
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We weren't using the gpt-labelled one, so I took it out of
createhdds; that makes the name of the mbr-labelled one lose
its label tag, so we need to update that name here.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
fd files don't work on aarch64, it seems. Drop BIOS even though
it's probably not breaking anything as I don't intend to move
aarch64 to prod until prod is up to new openQA, so no need to
stay compatible.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In recent os-autoinst the old 'stuff it all in HDDMODEL' doesn't
work and tells you to do it like this. This way does work in the
older os-autoinst currently on prod too, so this should be fine.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're about to deploy recent os-autoinst to staging. The UEFI
stuff got rewritten since the version we currently have, and
this is now the recommended way to handle UEFI firmware. The
new vars shouldn't confuse the old code still deployed on prod,
it should just ignore these vars and keep working off the old
'UEFI=1' (which causes it to autodetect the file locations).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We updated the dispatcher code, but not the templates...so we
didn't have any actual tests to run on Silverblue images. Let's
fix that. Note this means we won't test F28 and earlier images
that still have 'AtomicWorkstation' as their subvariant any
more, unless I set up some sorta workaround in the dispatcher.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Time for the great video driver merry-go-round again...lately
we're having some issues with vt corruption and rendering over
the boot splash, let's try using 'std' driver to see if it
helps a bit. stg has been set up this way for a couple of days
and it's not blowing up at least.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
They can't be in universal as there's no install_default_upload
for them to run after. Let's just run on the Server DVD install
like we do many other post-install tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a set of jobs to test FreeIPA replication. We deploy
a server, deploy a replica of that server, then enrol a client
against the replica and run the client tests.
At first I was planning to add the replica testing into the
main set of FreeIPA tests, but the test ordering/blocking (via
mutexes and barriers and what-have-you) just turns into a big
nightmare that way. This way seems rather simpler to deal with.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
qemu 2.11.2 fixes#1403343, so we can go back to using qxl for
x86_64 VMs. Also, setting QEMUVGA doesn't actually do anything
on aarch64 (os-autoinst ignores it and sets up virtio graphics
instead), so let's not set it to avoid confusion.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
...to try and avoid running into RHBZ#1572916, which is killing
Rawhide tests it seems. Let's hope this doesn't result in host
entropy starvation. If it does I might try patching os-autoinst
to seed virtio-rng from /dev/urandom, not /dev/random...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds the FreeIPA server and client upgrade tests to a new
updates-server-upgrade flavor which fedora_openqa will schedule
for updates. This way, we can test whether updates break
FreeIPA upgrades, which is a request the FreeIPA team made to
me. This has been deployed on staging for the last week or so
and appears to work fine.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
KDE package set install constantly runs into #1541433. While
that's not being fixed, let's bump the disk size so we can see
if the install actually works.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Tweaking aarch64 settings a bit to try and improve reliability.
I'm going to cut down to 3 workers per box along with this.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reduces duplication, but it also means that if the FreeIPA
web UI module fails, the password change module will pick up
from a point where Firefox is set up and won't fail in a bogus
way because it isn't.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This doesn't really work, it needs a product with that explicit
version to make it work, apparently. I think I'd better just
take this out and read up again on how the wildcards work rather
than just messing around with it. I'll put it back if I can be
reasonably sure of making it work.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Sigh, 'overloaded' product templates like that don't quite work.
So, let's try doing it a different way, in main.pm.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Workstation live installs for F28+ drop the user creation and
root password panes from anaconda, so we need to not try and
use them any more. But we still want the old behaviour for F27.
I'm hoping this approach will work, if not, we'll find out soon
enough. This removes the install_no_user test for F28+ as it
will no longer differ from the install_default test.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Atomic was renamed AtomicHost, and Workstation Ostree was renamed
AtomicWorkstation, for F28+. As we still have F26 and F27 images
which will have the Atomic name, we duplicate those templates,
but there should be no more 'Workstation Ostree' images, so we
just rename those templates to the new name.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is currently broken, but openQA doesn't notice; we really
should. We could also check the default in other cases, but I
think that's less clear-cut, as it's kind of an anaconda design
choice, it's not mandated in Fedora requirements anywhere.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
virtio graphics still seem to suffer from RHBZ#1403365, and also
os-autoinst believes they don't support snapshotting. So let's
try qxl for x86_64 UEFI. *That* may still suffer from #1403343,
but oh well, seems like we have no good choices here.
It looks like ppc64 also suffers from the Plymouth bug that's
affecting x86_64 UEFI + 'std' graphics, so let's use virtio
there - qxl apparently isn't available on ppc64 VMs, at least it
doesn't work in our deployment.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
While Rawhide suffers from #1518464 , virtio is a better choice
for UEFI tests, even if we get the problem with consoles using
the wrong color scheme again...
