Make sure to wait for the container to exit after kill. While the
cleanup process will take care eventually of transitioning the state, we
need to give a guarantee to the user to leave the container in the
expected state once the (kill) command has finished.
The issue could be observed in a flaking test (#16142) where
`podman rm -f -t0` failed because the preceding `podman kill`
left the container in "running" state which ultimately confused
the "stop" backend.
Note that we should only wait for the container to exit when SIGKILL is
being used. Other signals have different semantics.
[NO NEW TESTS NEEDED] as I do not know how to reliably reproduce the
issue. If #16142 stops flaking, we are good.
Fixes: #16142
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
The new cobra update fixed a bug which caused some options to not be
included in --help when there was already a option with the same name
on a parent command.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Basically, in the timeout loop where we checked for new CID
on the restarted container, we were running 'podman inspect'
(not 'inspect --format ID'), and comparing full hundred-line
output against single-line CID string.
While I'm in here, add 'c_' prefix to container to make it
easier for my old eyes to recognize "oh, that's a container name"
vs "is that a name? a SHA? a woozle?"
Signed-off-by: Ed Santiago <santiago@redhat.com>
Fix the "stop" on-failure action by not removing the transient systemd
timer and service during container stop. Removing the service will
in turn cause systemd to terminate the Podman process attempting to
stop the container and hence leave it in the "stopping" state.
Instead move the removal into the restart sequence.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Make sure that the on-failure actions only kick in once the health check
has passed its retries. Also fix race conditions on reading/writing the
log.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
In order to allow pods to reach other pods (as in Kubernetes) they all
need to be added to the same network. A network is created (if it
doesn't exist) and pods created by play-kube are added to that network.
When network options are passed to kube command the pods are not
attached to the default kube network.
Signed-off-by: Andrei Natanael Cosma <andrei@intersect.ro>
Include the digest of the image in `podman container inspect`. The image
digest is a key information for auditing as it defines the identify of
an image. This way, it can be determined whether a container used an
image with a given CVE etc.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
I see no reason to block --network host with kube play and force users
to have to set it in the yaml file.
This is just confusing when compared to the other podman create/run
--network options, see discussion in #15945.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Fixed issue where executing the command `podman pod logs -l` would panic
because it was indexing into an empty arguments array.
Signed-off-by: Jake Correnti <jcorrenti13@gmail.com>
Since by default the network config dir is shared in the e2e tests any
other parallel running test could remove a network and cause this test to
fail.
Fixes#15990
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The `podman run` command has been extended with support for checkpoint
images. A checkpoint image contains image files generated by criu that
allow to restore the runtime state of containerized applications. This
patch adds a test case for this functionality.
Signed-off-by: Radostin Stoyanov <radostin@redhat.com>
This reverts commit 32f54a81ed.
`pkg/bindings` is supported outside of podman and we have to keep it
stable.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
I was testing --log-level by --storage-opt=mount_program=/bin/false
Stop doing that. It's just constantly breaking everything (#15698
and #15977).
I am violently of the opinion that a command-line option must
not destroy a user's system (except for --set-something, --config,
something that makes it very very clear that it is a lasting
change). I seem to be in the minority on this opinion. So, I
give up.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Followup to #15895:
- add a normal-case test, to ensure that --privileged without
systemd continues to pass through /dev/ttyN devices
- explain why we die() if host has no ttyN devices
- I find grep -vx slightly easier to read than sed backslash-slash
- run cleanup with '-t 0', to shave ten seconds from CI run
Signed-off-by: Ed Santiago <santiago@redhat.com>
Auto updates using the "registry" policy require container to be created
with a fully-qualified image reference. Short names are not supported
due the ambiguity of their source registry. Initially, container
creation errored out for non FQN images but it seems that Podman has
regressed.
Fixes: #15879
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
We force the isolate option on new newtworks because that is the docker
behavior. However when we inspect them they should not be displayed to
the caller since they have no idea about it and docker-compose throws an
error because of that.
Fixes#15580
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Changes since 2022-09-09:
- man page: add --skip-unused-stages (buildah 4249)
- man page: bring in new Note for --cache-ttl (4248)
- system tests: de-stutter (4205)
- (internal): in skip() applier: escape asterisk, otherwise
the "bud with --dns* flags" sed expression never applies.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
restore endpoint was totally ignoring --pod, it was missing from the schema and from query handling
on the api handlers side. add support for it here.
resolves#15018
Signed-off-by: cdoern <cbdoer23@g.holycross.edu>
This allows tools like Cockpit to know that the pod in question
has also been updated, so they can refresh the list of containers
in the pod.
Fixes#15408
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
We added the concept of image volumes in 2.2.0, to support
inspecting an image from within a container. However, this is a
strictly read-only mount, with no modification allowed.
By contrast, the new `image` volume driver creates a c/storage
container as its underlying storage, so we have a read/write
layer. This, in and of itself, is not especially interesting, but
what it will enable in the future is. If we add a new command to
allow these image volumes to be committed, we can now distribute
volumes - and changes to them - via a standard OCI image registry
(which is rather new and quite exciting).
Future work in this area:
- Add support for `podman volume push` (commit volume changes and
push resulting image to OCI registry).
- Add support for `podman volume pull` (currently, we require
that the image a volume is created from be already pulled; it
would be simpler if we had a dedicated command that did the
pull and made a volume from it)
- Add support for scratch images (make an empty image on demand
to use as the base of the volume)
- Add UOR support to `podman volume push` and
`podman volume pull` to enable both with non-image volume
drivers
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
According to https://systemd.io/CONTAINER_INTERFACE/, systemd will try take
control over /dev/ttyN if exported, which can cause conflicts with the host's tty
in privileged containers. Thus we will not expose these to privileged containers
in systemd mode, as this is a bad idea according to systemd's maintainers.
Additionally, this commit adds a bats regression test to check that no /dev/ttyN
are present in a privileged container in systemd mode
This fixes https://github.com/containers/podman/issues/15878
Signed-off-by: Dan Čermák <dcermak@suse.com>
Background: in order to add aarch64 tests, we had to add
emergency skips to a lot of failing tests. No attempt was
ever made to understand why they were failing.
Fast forward to today, I filed #15888 just to see if tests
are still failing. Looks like a number of them are fixed.
(Yes, magically). Remove those skips.
See: #15074, #15277
Signed-off-by: Ed Santiago <santiago@redhat.com>
