"executable file not found in" is part of a runc
specific output when 'runc exec' fails.
This prevents the execsync failure to pass when running
ocid with other runtimes than runc.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Some OCI container runtimes (in particular the hypervisor
based ones) will typically create a shim process between
the hypervisor and the runtime caller, in order to not
rely on the hypervisor process for e.g. forwarding the
output streams or getting a command exit code.
When executing a command inside a running container those
runtimes will create that shim process and terminate.
Therefore calling and monitoring them directly from
ExecSync() will fail. Instead we need to have a subreaper
calling the runtime and monitoring the shim process.
This change uses conmon as the subreaper from ExecSync(),
monitors the shim process and read the exec'ed command
exit code from the synchronization pipe.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Some OCI container runtimes (in particular the hypervisor
based ones) will typically create a shim process between
the hypervisor and the runtime caller, in order to not
rely on the hypervisor process for e.g. forwarding the
output streams or getting a command exit code.
With these runtimes we need to monitor a different process
than the runtime one when executing a command inside a
running container. The natural place to do so is conmon
and thus we add a new option to conmon for calling the
runtime exec command, monitor the PID and then return the
running command exit code through the sync pipe to the
parent.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
waitpid fills its second argument with a value that
contains the process exit code in the 8 least significant
bits. Instead of returning the complete value and then
convert it from ocid, return the exit status directly
by using WEXITSTATUS from conmon.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In later versions of runC, `runc kill` *requires* the signal parameter
to know what signal needs to be sent.
Signed-off-by: Aleksa Sarai <asarai@suse.com>
We create 2 pods in 2 different networking namespace and
we check if we can ping one from the other.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When removing a pod sandbox or container, remove the ID of the item from
the corresponding ID index, so that we can correctly determine if it was
us or another actor that cleaned them up.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
The client size field that we get back when we inspect an image is a
pointer to a number, not just a number, so we need to dereference it for
display.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
We create temporary CNI networking configurations and run 2
functional tests:
- Verify that the networking namespace interface has a valid CIDR
- Ping the networking namespace interface from the host
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
We add 2 ocid options for choosing the CNI configuration and plugin
binaries directories: --cni-config-dir and --cni-plugin-dir.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Add an intermediate API layer that uses containers/storage, and a
containers/image that has been patched to use it, to manage images and
containers, storing the data that we need to know about containers and
pods in the metadata fields provided by containers/storage.
While ocid manages pods and containers as different types of items, with
disjoint sets of IDs and names, it remains true that every pod includes
at least one container. When a container's only purpose is to serve as
a home for namespaces that are shared with the other containers in the
pod, it is referred to as the pod's infrastructure container.
At the storage level, a pod is stored as its set of containers. We keep
track of both pod IDs and container IDs in the metadata field of
Container objects that the storage library manages for us. Containers
which bear the same pod ID are members of the pod which has that ID.
Other information about the pod, which ocid needs to remember in order
to answer requests for information about the pod, is also kept in the
metadata field of its member containers.
The container's runtime configuration should be stored in the
container's ContainerDirectory, and used as a template. Each time the
container is about to be started, its layer should be mounted, that
configuration template should be read, the template's rootfs location
should be replaced with the mountpoint for the container's layer, and
the result should be saved to the container's ContainerRunDirectory,
for use as the configuration for the container.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Any binary that will be managing storage needs to initialize the reexec
package in order to be able to apply or read image layers.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Update the versions of containers/storage and containers/image, and add
new dependencies that they pull in.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Add the necessary build tags and configuration so that integration tests
can properly build against device mapper and btrfs libraries.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
