CRI-O works well with runc when stopping a container because as soon
as the container process returns, it can consider every container
resources such as its rootfs as being freed, and it can proceed
further by unmounting it.
But in case of virtualized runtime such as Clear Containers or Kata
Containers, the same rootfs is being mounted into the VM, usually as
a device being hotplugged. This means the runtime will need to be
triggered after the container process has returned. Particularly,
such runtimes should expect a call into "state" in order to realize
the container process is not running anymore, and it would trigger
the container to be officially stopped, proceeding to the necessary
unmounts.
The way this can be done from CRI-O, without impacting the case of
runc, is to explicitly wait for the container status to be updated
into "stopped" after the container process has returned. This way
CRI-O will call into "state" as long as it cannot see the container
status being updated properly, generating an error after a timeout.
Both PollUpdateStatusStopped() and WaitContainerStateStopped() make
use of go routines in order to support a timeout definition. They
follow the waitContainerStop() approach with chControl.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
If the pid namespace mode is set to POD, then the container's namespace
should be set to the namespace of the pod infra container.
Signed-off-by: umohnani8 <umohnani@redhat.com>
Umount/Remove below can go wrong and next calls to NetNsRemove would
trigger:
481 Feb 22 14:37:35 ip-172-31-48-190.ec2.internal
atomic-openshift-node[88937]: E0222 14:37:35.291692 88937
remote_runtime.g o:115] StopPodSandbox
"200a062985ebfda2bbdb1b5d724005d4a0c1be54f277a4de52f9f101d9c43db6" from
runtime service failed: rpc error: code = Unknown desc = close
/var/run/netns/k8s_psql-1-tht5r_bingli328usyu727s_6a7b8edc-174d-11e8-9e8f-0a46c474dfe0_
0-dda1c649: file already closed
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
This uses the previously unusued lib/stats.go code to return data
about container stats to the CRI API. Helpers have been built around
filtering based on the OCI API, and CPU stat reporting has been fixed.
No data on filesystem layer usage is returned at this time.
Fixes one-half of #1248
Signed-off-by: Yann Ramin <atrus@stackworks.net>
We need to record whether the sandbox is using hostnetwok because the
kubelet needs that information when computing pod changes. Without this
patch it could happen that a pod that's using host network is restarted
just because the sandbox's status isn't reporting that it's running
using host network.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
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>
If a packager wants to be able to support addititional arguments on his
hook this will allow them to setup the configuration with these arguments.
For example this would allow a hook developer to add support for a --debug
flag to change the level of debugging in his hook.
In order to complete this task, I had to vendor in the latest
github.com://opencontainers/runtime-tools, which caused me to have to fix a
Mount and Capability interface calls
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We accidently defined hooks using stages rather then stage,
which causes all of the hooks not to work, but we saw no
complaints in the log files about this.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Should fix a possible deadlock in, at least, ListPodSandbox.
There seems to be no reason to hold stateLock when doing operations on
the memory_store for containers and sandboxes.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
