1
0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-12-23 02:33:08 +00:00
Commit Graph

4 Commits

Author SHA1 Message Date
Adam Williamson
92d52c6ac6 Split VNC client steps in two for aarch64 timing issue
So, there's a problem with how we figure out the NetworkManager
connection to use in setup_tap_static: it expects the first
connection in the list to be the right one, but this is only
actually true so long as it's *active*. When we're in the tap
case, it's usually not going to actually *work* out of the box
on boot (or else we wouldn't need setup_tap_static at all...),
so some time after boot, NetworkManager gives up on it and marks
it as inactive. And after that, setup_tap_static won't work any
more.

I never noticed this as a problem before because usually we do
setup_tap_static before that point. But it seems in the vnc
client tests, on aarch64, desktop boot and login is slow enough
that by the time we switch to a VT and try to setup the network,
we're very close to that cutoff, and sometimes miss it.

This, I hope, avoids the problem by doing the network setup in
that test before we deal with the desktop login, then doing the
desktop login, then doing the actual VNC bits.

The alternative here would be to figure out a better way to do
setup_tap_static, but I can't.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 12:39:52 -07:00
Adam Williamson
72edbfe991 Use qemu host IP 172.16.2.2 not 10.0.2.2
This is to make the infra folks happy, apparently using 10.0.x.x
and 10.1.x.x is causing conflicts since our actual infra network
uses those ranges too.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-23 16:40:45 -07:00
Adam Williamson
e9fa0b4bde Change type_safely in VNC tests to type_very_safely
We seem to have problems with the typing here on ppc64le, so
let's make it safer.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-15 15:13:44 +00:00
Adam Williamson
4c05f19a9f Add QA:Testcase_Anaconda_User_Interface_VNC_Vncconnect tests
This adds tests for vncconnect, a variation on VNC install using
reverse VNC (where the client waits for the server to connect to
it). Very similar to the regular-VNC test, but we have to use
tigervnc as Boxes doesn't do reverse VNC.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-11-06 17:42:29 -08:00