1
0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-12-11 05:43:11 +00:00
Commit Graph

6 Commits

Author SHA1 Message Date
Adam Williamson
1a65993d36 Add a perltidy check and apply it to the entire codebase
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-28 14:38:38 -07:00
Adam Williamson
bace4170f4 Wait longer before exiting _podman_client
At the end of _podman_client we create a mutex that we want the
server to pick up. If we exit too soon, the mutex goes away and
the server test fails. 5 seconds turns out to be not enough of a
wait because, although the server retries the lock call every
5 seconds, it can hit `api_call_2 failed` and wait 10 seconds
before retrying. Let's wait 30 seconds just to be safe.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-03-08 14:25:40 -08:00
Adam Williamson
c9609cf26d Drop bypass_1691487 function and usage (bug seems fixed)
Per https://bugzilla.redhat.com/show_bug.cgi?id=1691487#c14 it
seems like the bug here got fixed along the way and we probably
don't need this any more.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-05-06 09:02: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
35f17cb549 Have podman client test sleep a bit after creating the lock
It seems the server can miss it if the client creates it then
immediately exits.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-05 12:32:53 -07:00
Adam Williamson
14b21866f2 Add QA:Testcase_Podman test and run it on IoT (#166)
This adds a pair of tests, one which does almost all the work
from the test case, the other just a client test to check that
we can connect to an HTTP server running in a container on the
host. We also have to bump the _console_wait_login timeout on
this path a bit as we're booting a disk image that was installed
with DHCP working, but we change the network setup so DHCP does
not work any more, and the system spends quite some time trying
to bring the network up on boot before eventually giving up and
proceeding.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-05-28 14:55:27 -07:00