We were only including the CNI Network fields in the output of
`podman inspect` when the container was not running. It's simple
enough to fix (populate with empty structs, since we can't fill
anything without a CNI response to get IP address assigned, etc).
This is necessary for Docker compatibility.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
When we try, but fail, to load the default seccomp profile, say that,
instead of suggesting that we tried to load a profile with no name.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Previously, the order of OCI error messages was reversed, so that the
type of error was listed as the cause. For example:
Error: writing file `cpu.cfs_quota_us`: Invalid argument: OCI runtime error
This error message makes it seem like "OCI runtime error" is the
argument that was invalid. In fact, "OCI runtime error" is the error and
"writing file ..." is the cause. With this change, the above message
reads:
Error: OCI runtime error: writing file `cpu.cfs_quota_us`: Invalid argument
Signed-off-by: Jordan Christiansen <xordspar0@gmail.com>
In the past, Toolbox[0] has been affected by several of Podman's
bugs/changes of behaviour. This is one of the steps to assure that as
Podman progresses, Podman itself and subsequently Toolbox do not regress.
One of the other steps is including Toolbox's system tests in Podman's
gating systems (which and to what extent is yet to be decided on).
The tests are trying to stress parts of Podman that Toolbox needs for
its functionality: permission to handle some system files, correct
values/permissions/limits in certain parts, management of users and
groups, mounting of paths,.. The list is most likely longer and
therefore more commits will be needed to control every aspect of the
Toolbox/Podman relationship :).
Some test cases in test/e2e/toolbox_test.go rely on some tools being
present in the base image[1]. That is not the case with the common
ALPINE image or the basic Fedora image.
Some tests might be duplicates of already existing tests. I'm more in
favour of having those duplicates. Thanks to that it will be clear what
functionality/behaviour Toolbox requires.
[0] https://github.com/containers/toolbox
[1] https://github.com/containers/toolbox/#image-requirements
Signed-off-by: Ondřej Míchal <harrymichal@seznam.cz>
Currenly if a user specifies the name or ID of an external storage
container, we report an error to them.
buildah from scratch
working-container-2
podman rm working-container-2
Error: no container with name or ID working-container-2 found: no such container
Since the user specified the correct name and the container is in storage we
force them to specify --storage to remove it. This is a bad experience for the
user.
This change will just remove the container from storage. If the container
is known by libpod, it will remove the container from libpod as well.
The podman rm --storage option has been deprecated, and removed from docs.
Also cleaned documented options that are not available to podman-remote.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Following commands:
* systemd generate
* networks inspect
* pod stats
* Fixed test where format was quoted and then quoted again
* Fixed bug where output never printed '--' on missed reads
* pod ps
Signed-off-by: Jhon Honce <jhonce@redhat.com>
It is not set based on the root image directory, and always
points at the defaults. This change will get it to follow
filepath.Join(ir.store.GraphRoot(), "cache") set from libpod.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
When we create a container, we assign a cgroup parent based on
the current cgroup manager in use. This parent is only usable
with the cgroup manager the container is created with, so if the
default cgroup manager is later changed or overridden, the
container will not be able to start.
To solve this, store the cgroup manager that created the
container in container configuration, so we can guarantee a
container with a systemd cgroup parent will always be started
with systemd cgroups.
Unfortunately, this is very difficult to test in CI, due to the
fact that we hard-code cgroup manager on all invocations of
Podman in CI.
Fixes#7830
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
with the recent inclusion of dealing with multiple images in a tar archive, we can now add a compatibility endpoint that was missing images/get?names=one,two.
Fixes: #7950
Signed-off-by: baude <bbaude@redhat.com>
In Podman 1.9.3, `podman run -p 80` would assign port 80 in the
container to a random port on the host. In Podman 2.0 and up, it
assigned Port 80 in the container to Port 80 on the host. This is
an easy fix, fortunately - just need to remove the bit that
assumed host port, if not given, should be set to container port.
We also had a test for the bad behavior, so fix it to test for
the correct way of doing things.
Fixes#7947
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Also removed automatic exection of setup_environment.sh since most
people using this script are podman developers (not automation/CI
folks). If executing the automation scripts is necessary, manual
attendance to required variables like `$TEST_FLAVOR` is mandatory.
Signed-off-by: Chris Evich <cevich@redhat.com>
when using the compatibility mode as rootless, containers that were created were not setting their host names correctly due to the netmode not being set.
Fixes: #7934
Signed-off-by: baude <bbaude@redhat.com>
