Moves to the containerd/log package over logrus directly. This benefits the
traces because if using any log context such as OpenCensus on the entry gRPC
API all traces for that gRPC method will now contain the appropriate TraceID,
SpanID for easy correlation.
Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>
Only compose full container log path if neither of the paths is empty. Otherwise container won't start properly.
Signed-off-by: Cong Liu <conliu@google.com>
This bumps the containerd and sys packages in CRI
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Remove runtime-tools
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Update tests for oci opts package
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Because RunPodSandbox and CreateContainer will access metadata
without check, pod or container config file without metadata will
crash containerd.
This patch add checks to handle the issue.
Fixes: #1009
Signed-off-by: Hui Zhu <teawater@hyper.sh>
To match expectations of users coming from Docker engine runtime, add
the HOSTNAME to the environment of new containers in a pod.
Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
Also add new dependencies on github.com/xeipuuv/gojson* (brought up by
new runtime-tools) and adapt the containerd/cri code to replace the APIs
that were removed by runtime-tools.
In particular, add new helpers to handle the capabilities, since
runtime-tools now split them into separate sets of functions for each
capability set.
Replace g.Spec() with g.Config since g.Spec() has been deprecated in the
runtime-tools API.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Some CRI compatible runtimes may not support provileged operations.
Specifically hypervisor based runtimes (like kata-containers, cc-runtime
and runv) do not support privileged operations like:
- Provide access to the host namespaces
- Create fully privileged containers with access to host devices
Hypervisor based runtimes create container workloads within virtual machines.
When a running host privileged containers using them,
they wont provide support to requested the privileged opertations.
This commits add the new options to define two runtimes:
Trusted runtime : Used when a privileged container is requested.
Default runtime : for non-privileged workloads.
A container that belongs to a privileged pod will inherent this property
an will be created with the trusted runtime.
- Add options to define trusted runtime
- Add logic to decide if a sanbox is trusted
- Export annotation containers below to a trusted sandbox
Signed-off-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>