Along with type(Sandbox or Container) and Sandbox name annotations
provide support for additional annotation:
- Container name
This will help us perform per container operation by comparing it
with pass through annotations (eg. pod metadata annotations from K8s)
Signed-off-by: Chethan Suresh <Chethan.Suresh@sony.com>
This commit adds a flag to the runtime config that allows overloading of the default
privileged behaviour. When the flag is enabled on a runtime, host devices won't
be appended to the runtime spec if the container is run as privileged.
By default the flag is false to maintain the current behaviour of privileged.
Fixes#1213
Signed-off-by: Alex Price <aprice@atlassian.com>
By default the SecurityContext for Container activation can contain a Username
UID, GID. The order of precedences is username, UID, GID. If none of these
options are specified as a last resort attempt to set the ImageSpec username.
Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>
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>
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>
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>
For hypervisor-based container runtimes (like Kata Containers, Clear Containers
or runv) a pod will be created in a VM and then create containers within the VM.
When a runtime is requested for container commands like create and start, both
the instal "pause" container and next containers need to be added to the pod
namespace (same VM).
A runtime does not know if it needs to create/start a VM or if it needs to add a
container to an already running VM pod.
This patch adds a way to provide this information through container annotations.
When starting a container or a sandbox, 2 annotations are added:
- type (Container or Sandbox)
- sandbox name
This allow to a VM based runtime to decide if they need to create a pod VM or
container within the VM pod.
Signed-off-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>