Several podman commands accept no subcommands. Some
of those were not actually checking, though, which
could lead to user confusion. Added validation where
missing; and, refactored to minimize duplication.
(Side note: I decided against using cobra.NoArgs
because its error message, "unknown command",
misleadingly implies that there are known ones).
Also added validation to varlink
Signed-off-by: Ed Santiago <santiago@redhat.com>
Also add some extra debug information to help figure out what's
going on when stop goes bad.
Fixes: #2472
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
With the change to cobra, the following command fails:
# podman create alpine sh -c /bin/true
Error: unknown shorthand flag: 'c' in -c
(Correct behavior is to pass '-c' to the container command)
This PR corrects that.
Signed-off-by: Ed Santiago <santiago@redhat.com>
* ps now on main command
* sign is no longer on main commmand
* ls, list no longer are valid main aliases for images
* ls, list does work for podman image
Signed-off-by: baude <bbaude@redhat.com>
We had a regression on master where we broke the build for
non-Varlink builds. Catch this in CI in the future.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
There is currently still one SELinux related checkpoint/restore problem:
https://github.com/containers/libpod/issues/2334
To avoid unnecessary CI failures the checkpoint/restore tests are
temporarily disabled on Fedora.
It is not necessary to disable the tests on Ubuntu as it is running
without SELinux and it is also not necessary to disable the RHEL 7 tests
as RHEL's CRIU is too old to run the checkpoint/restore tests at all.
Signed-off-by: Adrian Reber <areber@redhat.com>
The commands checkpoint and restore should only be available under
'podman container'. This is probably a result of the recent cobra
migration.
Signed-off-by: Adrian Reber <areber@redhat.com>
Conceptually simple: include, where applicable, a brief
description of command-line options for each subcommand.
Signed-off-by: Ed Santiago <santiago@redhat.com>
No reason to do it in util/ anymore. It's always going to be a
subdirectory of c/storage graph root by default, so we can just
set it after the return.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
There are some cases where we might not be properly adjusting the
volume path after setting the storage graph root. Ensure that we
always set volume path to be a child of graph root.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
This release updates buildah to use containers/image v1.5
Which fixes a crash issue when pulling container images.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Instead of passing in defaults via WithStorageConfig after
computing them in cmd/podman/libpodruntime, do all defaults in
libpod itself.
This can alleviate ordering issues which caused settings in the
libpod config (most notably, volume path) to be ignored.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
when podman generate kube runs, it names the pod based on the first
container it finds. the resulting yaml file is perfectly acceptable
in a kubernetes environment. But when replaying the YAML file
with podman, we cannot have a container and pod with the same name.
therefore, we rename the pod if find a collision to name_pod.
Signed-off-by: baude <bbaude@redhat.com>
if there is already a bind mount specified for the target, do not
create a new volume.
Regression introduced by 52df1fa7e054d577e8416d1d46db1741ad324d4a
Closes: https://github.com/containers/libpod/issues/2441
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
When removing volumes with rm --volumes we want to only remove
volumes that were created with the container. Volumes created
separately via 'podman volume create' should not be removed.
Also ensure that --rm implies volumes will be removed.
Fixes#2441
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
'podman logs -l' was no longer working. This fixes it by replacing
&waitCommand.Latest with &logsCommand.Latest.
Signed-off-by: Adrian Reber <areber@redhat.com>
when using the play kube command, we need to make sure that containers
with dependancies are started in proper order. in this case, the infra
container must be started first.
Signed-off-by: baude <bbaude@redhat.com>
If this doesn't match, we end up not being able to access named
volumes mounted into containers, which is bad. Use the same
validation that we use for other critical paths to ensure this
one also matches.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
