This will avoid the goroutines leak we've been seeing during
performance tests. Goroutines count returns to normal after containers
cleanup.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Allows the user to define secret paths in /etc/containers/mounts.conf
These are then volume mounted into the container
Signed-off-by: umohnani8 <umohnani@redhat.com>
Running crio with -debug is very verbose. Having more granularity
on the log level can be useful when e.g. only looking for errors.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
runc has a `--no-pivot` flag, that uses MS_MOVE instead.
This patch set bubbles up a runtime config to enable using no-pivot
globally.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Add new directory /etc/crio/hooks.d, where packagers can drop a json config
file to specify a hook.
The json must specify a valid executable to run.
The json must also specify which stage(s) to run the hook:
prestart, poststart, poststop
The json must specify under which criteria the hook should be launched
If the container HasBindMounts
If the container cmd matches a list of regular expressions
If the containers annotations matches a list of regular expressions.
If any of these match the the hook will be launched.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
kpod must parse the crio configuration file or the storage
is not set up correctly. By default it is not. We now read
/etc/crio/crio.conf in as the configuration file unless it is
overriden by the user and the global -c|--config switch.
Signed-off-by: baude <bbaude@redhat.com>
This allows the container list API to return updated status
for exited container without having to call container status first.
Signed-off-by: Mrunal Patel <mpatel@redhat.com>
We add two flags --enable-metrics and --metrics-port
to enable metrics endpoint and allow specifying the
port which defaults to 9090.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Need to mv to latest released and supported version of logrus
switch github.com/Sirupsen/logrus github.com/sirupsen/logrus
Also vendor in latest containers/storage and containers/image
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Make getStore() take a config struct from which it pulls the store
options, then update the kpod commands so that they call getConfig()
and pass the config into getStore()
Signed-off-by: Ryan Cole <rcyoalne@gmail.com>
The syscall package is locked down and the comment in [1] advises to
switch code to use the corresponding package from golang.org/x/sys. Do
so and replace usage of package syscall where possible (leave
syscall.SysProcAttr and syscall.Stat_t).
[1] https://github.com/golang/go/blob/master/src/syscall/syscall.go#L21-L24
This will also allow to get updates and fixes just by re-vendoring
golang.org/x/sys/unix instead of having to update to a new go version.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
This patch also hides the profile under the debug flag as there's
runtime cost to enable the profiler.
This removes the old way of profiling (CPU) as that's not really
needed.
Signed-off-by: Antonio Murdaca <runcom@redhat.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>