containers-common seems to have inadvertently introduced a hard
dependency on composefs, but not expressed it as a package dep.
While I'm trying to get that fixed, let's ensure the podman and
toolbox tests don't fail on it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Per https://github.com/containers/podman/pull/19302 and
https://github.com/containers/podman/issues/19299 , upstream
have kindly set things up so we can easily run relevant parts of
the upstream test suite as an integration test in openQA. This
should help us catch if changes in other components break key
features of podman.
This only runs any tests with podman 4.6.1 or higher, but with
earlier versions it just does nothing and exits 0, so that's
fine. 4.6.1 is in F39 and Rawhide already, will land for F37
and F38 shortly.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It has been noted that updates have broken podman in the past and
this is a major issue for some users. Let's create a new update
flavor and run the test in it. We'll use the server image as a
base, but it's not really a server test, so I'm giving it its own
flavor so it's not run on updates that we only want to run server
tests on, and we can schedule just this test to run on container-y
updates.
As part of this, we need to install podman before running the
test; for flavors we currently run it on we expect podman to be
preinstalled, but that's not true for the server base image.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I tried to bump it before, but set it to 90, which is the default.
Sigh. So this is an actual bump. It looks like until 20201124 this
took about 80 seconds, now it's taking like 93.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
Adam Williamson
Paul Whalen