* Added flags to point to TLS PEM files to use for exposing and connecting
to an encrypted remote API socket with server and client authentication.
* Added TLS fields for system connection ls templates.
* Added special "tls" format for system connection ls to list TLS fields
in human-readable table format.
* Updated remote integration and system tests to allow specifying a
"transport" to run the full suite against a unix, tcp, tls, or mtls
system service.
* Added system tests to verify basic operation of unix, tcp, tls, and mtls
services, clients, and connections.
Signed-off-by: Andrew Melnick <meln5674.5674@gmail.com>
The distro-integration tag was added for fedora openQA to only run a
subset of tests. However since it was added only a few new tests have
been labelled like that and in general a normal contributor or even
maintianer has no idea when to add this tag.
We also have been seeing several regressions getting into fedora that
these tests would have caught. As such I worked with Adam to enable all
tests for fedora openQA so we actually have proper coverage. This has
been working for a few weeks so I think we can dop these tags so
upstream does not need to bother with them at all.
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/373
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
BATS 1.8.0 introduces tags: metadata that can be applied to
a single test or one entire file, then used for filtering
in a test run.
Issue #19299 introduces the possibility of using OpenQA
for podman reverse dependency testing: continuous CI on
all packages that can affect podman, so we don't go two
months with no bodhi builds then get caught by surprise
when systemd or kernel or crun change in ways that break us.
This PR introduces one bats tag, "distro-integration".
The intention is for OpenQA (or other) tests to install
the podman-tests package and run:
bats --filter-tags distro-integration /usr/share/podman/test/system
Goal is to keep the test list short and sweet: we do not
need to test command-line option parsing. We *DO* need to
test interactions with systemd, kernel, nethack, and other
critical components.
Signed-off-by: Ed Santiago <santiago@redhat.com>
There are quite a lot of places in podman were we have some signal
handlers, most notably libpod/shutdown/handler.go.
However when we rexec we do not want any of that and just send all
signals we get down to the child obviously. So before we install our
signal handler we must first reset all others with signal.Reset().
Also while at it fix a problem were the joinUserAndMountNS() code path
would not forward signals at all. This code path is used when you have
running containers but the pause process was killed.
Fixes#16091
Given that signal handlers run in different goroutines parallel it would
explain why it flakes sometimes in CI. However to my understanding this
flake can only happen when the pause process is dead before we run the
podman command. So the question still is what kills the pause process?
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
One of our oldest most frustrating flakes is #16091, "Timed
out waiting for BYE".
In #17489 we added some debug output to see if the problem
was a container hang of some sort. It does not seem to be
(see #17675), and the debug output makes it hard to read
failure logs, so let's remove it.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Install the signal proxy before attaching to/starting the container to
make sure there's no race-condition as revealed in the failing start/run
tests in #16901. The tests had the valid expectation that signal
forwarding works once the container is running.
Further update the tests to account for the attach test where the
expectation is that signal forwarding works once Podman has attached to
container (or even before).
Fixes: #16901
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Signed-off-by: Ed Santiago <santiago@redhat.com>
...and instrument with 'podman ps'es for debugging failures.
Test flakes pretty regularly in Fedora gating. If the increased
timeout doesn't help, at least we should be able to see if the
container is stopping or failed or something.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Bump the timeout waiting for the container to process the signal.
The comparatively short timeout is most likely responsible for
flakes in gating tests.
Fixes: #16091
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
