When returning error http code (e.g. 4xx, 5xx) the body needs to contain
a JSON that has a key "message" in it,
we must not use jsonmessage.JSONMessage.
The JSON of shape jsonmessage.JSONMessage is used only when client
already received 200.
Signed-off-by: Matej Vašek <matejvasek@gmail.com>
So when running remote and rootless tests the buildImage() thing has one
big problem because it used the main test tmpdir as context.
However that dir also holds all the image layers with files that are
owned by other uids and because podman-remote does not use the userns it
cannot read some files and then fails when trying to tar up the context
dir.
To fix this use an extra sub directory. Now because some tests where
using the parent directory to supply context files just switch the
callers so they have full control still.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The `podman stop - basic test` flakes in CI because $SECONDS is
integer-precision: a ~14.6s stop rounds to delta_t=15 and fails
the -le 14 check. Widen the upper bound to 18s, which still catches
real regressions while tolerating slow CI nodes and remote-mode
socket overhead.
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
After _check_health "First failure" returns with FailingStreak=2, the
3rd failure fires during the subsequent systemctl checks (~1s interval),
emitting the "unhealthy" event before current_time was captured. Move
current_time before those checks so --since doesn't miss the event.
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
Test: `podman container rm --force doesn't leave running processes`
Under CI load, podman-inspect takes 2-3s per call, longer than the
2s stop-timeout window. Increase to 20s so the test reliably catches
the "stopping" state before it transitions to "exited".
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
By default we run tests in parallel so when we mount test/certs with the
":Z" option it means only one container can read it, depending on the
startup times this can mean the container fails to start. I observed
this error in a CI run:
level=fatal msg="open /certs/domain.crt: permission denied"
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Because we use hard coded names anyway we might as well skip the extra
command execution here that happened for each test.
Just inline a valid htpasswd line. Also remove the extra sync call,
there is no reason whatsoever for this file to be synced.
For cp there is also no reason at all to call an external command. Worse
the command also was never checked for errors.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Pause the container by default during commit. It is safer as it
avoids conflicts, and potentially security issues, when another
process is accessing the container rootfs.
Originally this was not done because it was a breaking change and
rootless containers weren't able to use the freezer cgroup controller.
Now that we support only cgroup v2, there is no gap anymore with
root (exotic configurations can still use --pause=false).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
log_path is currently set at the client side and is ignored by
the server in a remote session. This leads to either incorrect log_path
being considered by the server or not honored at all. Move the handling
from client to the server, in line with other flags such as log_driver.
Signed-off-by: Danish Prakash <contact@danishpraka.sh>
Add CDI information to podman info and podman system info.
The host info now includes the configured CDI spec directories and the
currently discovered CDI devices. The devices are resolved when the info
endpoint is called and there is no need to refresh these in the background.
Also map the same data into the Docker-compatible /info response as CDISpecDirs and DiscoveredDevices.
Signed-off-by: Evan Lezar <elezar@nvidia.com>
The test flakes on the socat pid kill when the pid already exited.
Because the timeout is just 10s we can just bump it to something loinger
to ensure the process is still alive when we kill it. Also move it up a
bit so the kill happens earlier.
I observed multiple time failing with test times of 11s+. This should be
enough to make it work properly.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In the new CI with run with many parallel jobs (8) and that is messing
up timings a fair but, any command might take unexpected long to
scheduling delays and lock holding by other tests.
Any test doing a podman ps -a while need to take all container locks
for example and that then can delay the stop command an unknown amount
of time, bump the timeout to 8 and use a higher stop timeout so we are
still testing that we exit before the wait timeout is reached.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This started to fail on fedora rawhide with kernel 7.1. I have not
looked into why exactly why but the theory from commit 12d40777f0
is likely related. What I do not get is why this tests seem to pass
elsewhere, i.e. it passes in openQA and testing farm but not in our
custom lima based VMs.
Lets hope this works better.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
`podman run -ti` warns when stdin is not a tty, but if the container is
run in detached state that warning does not make much sense: we just
need the environment where podman attach will be run to be a tty.
Running with `-ti` even in detached state can make sense to avoid
applications buffering their output (for realtime logs) or allowing
later interaction and should not warn users.
Also remove the comment saying that warning will become fatal, as there
seems to be agreement that such a breaking change will not be made
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
It is possible that the background podman stop -t 1 completes before we
get to podman kill making the kill fail as the container is not running.
The result is this error in the test:
"Error: can only kill running containers. xxx is in state exited: container state improper"
We can just bump the stop timeout to have a larger time where we can
trigger kill on a stopping container.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The problem is by default we create the systemd timers and run hc in the
background. This means any tests who depend on exact hc timing can get
broken by this so use the DISABLE_HC_SYSTEMD=true env which makes podman
skip creating the systemd timers but still allows you to manually run
the commands.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
With a high parallel node run we have much more test cases run in
parallel, as such I am seeing a lot of network subnet flakes as they
were using the same one and thus failed since there can only be one
config using it at a time.
Now hard coding this here is ugly, yes. But for now I just need to get
the flakes down in the new CI. Long term we should likely have a helper
that hands out known unused subnets for the tests.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In parallel runs the timings might be a bit slower than normal. Increase
the timeout here, it should not affect the test as we use a 20s stop
timeout which is more than the ready loop which uses 5s now.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Add support for blackhole, unreachable, and prohibit route types in podman
networks. These route types allow silently discarding packets (blackhole),
rejecting with destination unreachable (unreachable), or rejecting with
administratively prohibited (prohibit).
Note: Blackhole routes require netavark >= 2.0.0. Regular unicast routes
remain backward compatible with all netavark versions.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
<MH: Rebased atop latest main & fixed cherry-pick conflicts>
Signed-off-by: Matt Heon <matthew.heon@pm.me>
podman ps -a causes unexpected timing delays as it tries to take locks for
all containers and parallel tests may cause it to block for a while.
In CI logs I see ps -a take over 3 seconds which is enough to mess with
the expect time and make the test fail. Since testing the ps -a output
as part of the test just switch the test to not run in parallel.
This failed with "delta t between paused and restarted" where it took 10
seconds instead of the max expected 6 seconds.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This is a long standing flake but I see it again in the lima CI, the
problem seems to happen when we stop the container before the background
healthcheck fires.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In highly parallel runs this can fail its timeout due the fact that we
run podman ps -a which takes all contianer locks, even the ones from
unrelated tests. thus this command can take a long time, from a CI log I
see:
[18:22:30.932958589] # /var/tmp/podman/bin/podman ps -a
[18:22:34.338904713] CONTAINER ID IMAGE
So like a 4s delay just on that and hence the test later failed with
"Operations took too long" as it took 7 seconds overall.
So since we know podman inspect takes the lock just keep that and not
try to get all containers for no reason.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This seems to flake in the parallel CI runs as another process might
also use 8080 already.
We can use any port here so use GetPort() which should give us a
conflict free one.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
I saw this already in openQA and now with the new rawhide images we hit
it in upstream as well. Skip this for now to not cause so many flakes.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This is really not nice but it is a quick fix to avoid more flakes.
The 10.11.12.0/24 was used by several tests and podman will only allow
the network to be created once with a given subnet so we need to ensure
they are conflict free, otherwise in parallel runs they will fail
randomly.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The container prints "Failed to set RLIMIT_CORE: Operation not permitted"
I do not know why this fails when run with sudo but lets just skip it it
for now.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The test assumes a local id_ed25519 ssh key exists and is setup to
connect to its own user. That is basically never the case locally so the
test is broken by design.
If the test should run in some special CI setup where that is the case
we need to enable it and guard based on that later.
For now I just like to get the lima VM tests passing.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The test assumed /home/$USER == $HOME which may not be the case. In fact
it is not the case in the new lima VM runners.
Fix the test to actually use the path we want to test for, $HOME.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
It is not working in all ipv6 setups. In the new lima testing env
default_addr is just null causing the test to fail because the container
address was "fec0::5055:55ff:fe2b:6cc9".
For now skip this until we can figure something better out.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
