Found images being returned which do have "Alpine" in the description.
However, test fails because podman truncates the field. Disabling test
since this is a long-term maintenance branch.
Signed-off-by: Chris Evich <cevich@redhat.com>
We've got some python tests running in CI, and they're really hard
to troubleshoot. This PR:
1) colorizes python unittest lines (ok / skipped / fail), and
2) links to source files
The color is nice for skimming, but it's the linking that might
make it much easier to diagnose future failures.
(Context: failure today in test/python/docker/compat/test_images.py)
Signed-off-by: Ed Santiago <santiago@redhat.com>
It looks like some descriptions have changed on the docker registry
where we had been searching for images that include 'alpine'. We are
now seeing an image in the initial list that has 'alpine' in its
description.
Signed-off-by: Brent Baude <bbaude@redhat.com>
For the since and after imagve filter tests, instead of using the
read-only cache of images, we just use the empty r/w store. We then
build three images that are strictly predictable.
Signed-off-by: Brent Baude <bbaude@redhat.com>
Prodding bz #2024229 a little more, it turns out the service file is NOT
deleted when it is in a failed state (i.e the healtch check has failed
for some reason). The state must be reset before the service is stopped
on container removal and then the files will be removed properly.
BZ#:2024229
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
when a container with healthchecks exits due to stopping or failure, we
need the cleanup process to remove both the timer file and the service
file.
Bz#:2024229
Signed-off-by: Brent Baude <bbaude@redhat.com>
This resolves CVE-2021-4024, where an attacker could access the
API externally and forward any port they desired to the VM from
`podman machine`.
[NO NEW TESTS NEEDED] gvproxy is not tested directly at this
time.
Signed-off-by: Matthew Heon <mheon@redhat.com>
`logs -f` with `journald` is supported only when `journald` events
backend is used. To pass system tests using `logs -f` in an environment
where `events_logger` is not set to `journald` in `containers.conf`,
this fix sets `--events-backend` or `--log-driver` temporally.
Signed-off-by: Hironori Shiina <shiina.hironori@jp.fujitsu.com>
<MH: Fixed cherry-pick conflicts>
Honor custom `target` if specified while running or creating containers
with secret `type=mount`.
Example:
`podman run -it --secret token,type=mount,target=TOKEN ubi8/ubi:latest
bash`
Signed-off-by: Aditya Rajan <arajan@redhat.com>
Our fedora-minimal image on Quay bases on fedora-minimal:latest which
starting with F35 removed a number of binaries that our CI depends on.
Fix that by pulling `fedora-minimal:34` from the Fedora registry
directly.
Once the build bot on Quay has been disabled, we move the image over
there to make sure that it will not change over time.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
we try hard to re-use the existing podman-pause.scope name when it
already exists, causing any sort of race errors when the already
existing scope is terminating.
There is no such a requirement though, so just try with a random
name.
Closes: https://github.com/containers/podman/issues/12065
[NO NEW TESTS NEEDED] it fixes a race in the CI
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Followup to #12229, in which I added a podman unshare for
flake debugging. Turns out that doesn't work in podman-remote.
It was not caught because CI doesn't run podman-remote rootless.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Patch originally by Paul Holzinger (sourced from [1]).
This is necessary to get the tests to pass in order to include a
batch of other, related journald fixes in `podman logs`.
[1] https://github.com/containers/podman/pull/12274#issuecomment-967168173
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
The cni plugins need access to /run/cni and the dnsname plugin needs
access to /run/containers.
The race condition was basically that a `podman stop` could either do the
cleanup itself or the spawned cleanup process would do the cleanup if it
was fast enough. The `podman stop` is executed on the host while the
podman cleanup process is executed in the "parent container". The parent
container contains older plugins than on the host. The dnsname plugin
before version 1.3 could error and this would prevent CNI from
doing a proper cleanup. The plugin errors because it could not find its
files in /run/containers. On my system the test always failed because
the cleanup process was always faster than the stop process. However in
the CI VMs the stop process was usually faster and so it failed only
sometimes.
Fixes#11558
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Podman and Docker will not commit changes via RUN command
of a VOLUME directory, so we need to chown path first.
Not doing do will cause: https://bugzilla.redhat.com/show_bug.cgi?id=2009266
Signed-off-by: Jindrich Novy <jnovy@redhat.com>
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We now do not copy the `bin` directory to the target nix sources to
avoid skipping the build because "everything is up to date".
Fixes https://github.com/containers/podman/issues/12198
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
When starting a container libpod/runtime_pod_linux.go:NewPod calls
libpod/lock/lock.go:AllocateLock ends up in here. If you exceed
num_locks, in response to a "podman run ..." you will see:
Error: error allocating lock for new container: no space left on device
As noted inline, this error is technically true as it is talking about
the SHM area, but for anyone who has not dug into the source (i.e. me,
before a few hours ago :) your initial thought is going to be that
your disk is full. I spent quite a bit of time trying to diagnose
what disk, partition, overlay, etc. was filling up before I realised
this was actually due to leaking from failing containers.
This overrides this case to give a more explicit message that
hopefully puts people on the right track to fixing this faster. You
will now see:
$ ./bin/podman run --rm -it fedora bash
Error: error allocating lock for new container: allocation failed; exceeded num_locks (20)
[NO NEW TESTS NEEDED] (just changes an existing error message)
Signed-off-by: Ian Wienand <iwienand@redhat.com>
- remove 'NO TESTS NEEDED' as a valid bypass string. Henceforth
only 'NO NEW TESTS NEEDED' will work.
- add a debugging aid for #11871, in which bodhi tests time out
in nslookup.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Address the TOCTOU when generating random names by having at most 10
attempts to assign a random name when creating a pod or container.
[NO TESTS NEEDED] since I do not know a way to force a conflict with
randomly generated names in a reasonable time frame.
Fixes: #11735
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
A comment was made on internal mailing list about confusion on SELinux
labeling of volumes. This PR makes it a little more clear about when
you should or should not relabel.
We need a similar comment in podman pod create, but it does not support
--security-opt processing yet.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The returned error was not checked, thus the test could hang forever
since it blocks on the log channel.
Also handle unexpectedEOF like EOF.
Fixes#12176
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
the --cgroups=split test changes the current cgroup as it creates a
sub-cgroup. This can cause a race condition in tests that are reading
the current cgroup.
Closes: https://github.com/containers/podman/issues/11191
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Instead using the OS-wide system default policy, use
the one in this repo, and adjust the expected results
(as well as making the test stricter).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This PR fixes the case when the API return HTTP 409 response. Where the
API return the body format different then for other HTTP error codes.
Signed-off-by: Ondra Machacek <omachace@redhat.com>
