on old kernels the ioctl NS_GET_PARENT is not available.
Handle the error code and immediately return the same fd. It should
be fine now that we use the namespace resolution using the conmon pid,
so the namespace parent resolution is just a safety measure.
Closes: https://github.com/containers/libpod/issues/2968
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
With multiple `containers` projects updating VM Image metadata,
it would be very difficult to discover which Cirrus-CI setup
was responsible. Add the GCE project name to the list
of metadata labels to update when this container runs. This
will give more context as to which images are currently in use.
Signed-off-by: Chris Evich <cevich@redhat.com>
The option to restore a container from an external checkpoint archive
(podman container restore -i /tmp/checkpoint.tar.gz) restores a
container with the same name and same ID as id had before checkpointing.
This commit adds the option '--name,-n' to 'podman container restore'.
With this option the restored container gets the name specified after
'--name,-n' and a new ID. This way it is possible to restore one
container multiple times.
If a container is restored with a new name Podman will not try to
request the same IP address for the container as it had during
checkpointing. This implicitly assumes that if a container is restored
from a checkpoint archive with a different name, that it will be
restored multiple times and restoring a container multiple times with
the same IP address will fail as each IP address can only be used once.
Signed-off-by: Adrian Reber <areber@redhat.com>
If restoring a container from a checkpoint it was necessary that the
image the container is based was already available (podman pull).
This commit adds the image download to podman container restore if it
does not exist.
Signed-off-by: Adrian Reber <areber@redhat.com>
The difference between container checkpoint/restore and container
migration is that for migration the container which was checkpointed
must not exist during restore. To simulate migration the container
is remove ('podman rm -fa') before being restored. The migration test
does following steps:
* podman run
* podman container checkpoint -l -e /tmp/checkpoint.tar.gz
* podman rm -fa
* podman container restore -i /tmp/checkpoint.tar.gz
Signed-off-by: Adrian Reber <areber@redhat.com>
This commit adds an option to the checkpoint command to export a
checkpoint into a tar.gz file as well as importing a checkpoint tar.gz
file during restore. With all checkpoint artifacts in one file it is
possible to easily transfer a checkpoint and thus enabling container
migration in Podman. With the following steps it is possible to migrate
a running container from one system (source) to another (destination).
Source system:
* podman container checkpoint -l -e /tmp/checkpoint.tar.gz
* scp /tmp/checkpoint.tar.gz destination:/tmp
Destination system:
* podman pull 'container-image-as-on-source-system'
* podman container restore -i /tmp/checkpoint.tar.gz
The exported tar.gz file contains the checkpoint image as created by
CRIU and a few additional JSON files describing the state of the
checkpointed container.
Now the container is running on the destination system with the same
state just as during checkpointing. If the container is kept running
on the source system with the checkpoint flag '-R', the result will be
that the same container is running on two different hosts.
Signed-off-by: Adrian Reber <areber@redhat.com>
This adds a couple of function in structure members needed in the next
commit to make container migration actually work. This just splits of
the function which are not modifying existing code.
Signed-off-by: Adrian Reber <areber@redhat.com>
Let's put inspect structs where they're actually being used. We
originally made pkg/inspect to solve circular import issues.
There are no more circular import issues.
Image structs remain for now, I'm focusing on container inspect.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
some integration tests are inherently problematic due to timing issues.
one such case is running a valid health check on container that runs
nginx. while the container may be running, nginx may not have finished
executing itself and therefore the healthcheck fails.
Signed-off-by: baude <bbaude@redhat.com>
we are allowed to use only signal safe functions between a fork of a
multithreaded application and the next execve. Since setenv(3) is not
signal safe, block signals. We are already doing it for creating a
new namespace.
This is mostly a cleanup since reexec_in_user_namespace_wait is used
only only to join existing namespaces when we have not a pause.pid
file.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
...with the goal of (very soon) reusing this code, in #2947,
to run system tests in CI. This is the cleanest way I can
think of to do so without duplication or a large maintenance
burden.
Changes are:
- replace references to 'ginkgo' with 'integration'. That
target is already in Makefile, and is not only more
readable, it's also more abstract. There is no reason
for this level of code to know about ginkgo.
- allow rootless_test.sh to accept an argument,
that being the name of the test suite to run
(default: integration). #2947 will enable 'system'.
- allow integration_test.sh to serve multiple purposes,
by checking its filename. #2947 will add a symlink,
system_test.sh, which will then cascade down to
invoke system tests.
Signed-off-by: Ed Santiago <santiago@redhat.com>
