We weren't setting the logPath of the sandbox when restoring sandboxes
and containers upon a crio restarts. That means that if you restart
CRI-O you get sandboxes with empty logPath. That means that when you're
starting a container in a restored sandbox you get a relative logPath
for the container:
sandboxLogPath: "/var/something"
- restore
sandboxLogPath: ""
- create container foo
containerLogPath: "foo_attempt.log"
With this patch we actually get an absolute path (which is correct):
sandboxLogPath: "/var/something"
- restore
sandboxLogPath: "/var/something"
- create container foo
containerLogPath: "/var/something/foo_attempt.log"
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
We add a ContainerVolume struct and store a list of volumes
in the Container object for quick retrieval.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
We calculate these values at container creation time and store
them in the container object as they are requested during container
status. This avoids re-calculation and speeds up container status.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Container runtimes provide different levels of isolation, from kernel
namespaces to hardware virtualization. When starting a specific
container, one may want to decide which level of isolation to use
depending on how much we trust the container workload. Fully verified
and signed containers may not need the hardware isolation layer but e.g.
CI jobs pulling packages from many untrusted sources should probably not
run only on a kernel namespace isolation layer.
Here we allow CRI-O users to define a container runtime for trusted
containers and another one for untrusted containers, and also to define
a general, default trust level. This anticipates future kubelet
implementations that would be able to tag containers as trusted or
untrusted. When missing a kubelet hint, containers are trusted by
default.
A container becomes untrusted if we get a hint in that direction from
kubelet or if the default trust level is set to "untrusted" and the
container is not privileged. In both cases CRI-O will try to use the
untrusted container runtime. For any other cases, it will switch to the
trusted one.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
We use a SOCK_SEQPACKET socket for the attach unix domain socket, which
means the kernel will ensure that the reading side only ever get the
data from one write operation. We use this for frameing, where the
first byte is the pipe that the next bytes are for. We have to make sure
that all reads from the socket are using at least the same size of buffer
as the write side, because otherwise the extra data in the message
will be dropped.
This also adds a stdin pipe for the container, similar to the ones we
use for stdout/err, because we need a way for an attached client
to write to stdin, even if not using a tty.
This fixes https://github.com/kubernetes-incubator/cri-o/issues/569
Signed-off-by: Alexander Larsson <alexl@redhat.com>
Some runtimes like Clear Containers need to interpret the CRI-O
annotations, to distinguish the infra container from the regular one.
Here we export those annotations and use a more standard dotted
namespace for them.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
