Kpod rm removes a container from the system
Signed-off-by: Ryan Cole <rcyoalne@gmail.com>
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Signed-off-by: umohnani8 <umohnani@redhat.com>
Found out that during OpenShift testing, node was trying to remove
containers (probably in a bad state) and was failing the removal with
this kind of error:
E0828 13:19:46.082710 1235 kuberuntime_gc.go:127] Failed to remove
container
"e907f0f46b969e0dc83ca82c03ae7dd072cfe4155341e4521223d9fe3dec5afb": rpc
error: code = 2 desc = failed to remove container exit file
e907f0f46b969e0dc83ca82c03ae7dd072cfe4155341e4521223d9fe3dec5afb: remove
/var/run/crio/exits/e907f0f46b969e0dc83ca82c03ae7dd072cfe4155341e4521223d9fe3dec5afb:
no such file or directory
I believe it's ok to ignore this error as it may happen conmon will
fail early before exit file is written.
Signed-off-by: Antonio Murdaca <runcom@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>
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>
Move non-kubernetes-dependent portions of server struct to libkpod.
So far, only the struct fields have been moved and not their dependent
functions
Signed-off-by: Ryan Cole <rcyoalne@gmail.com>
When starting pods or containers, we create the mount points
first. It seems natural to do something symetrical when stopping
pods or containers, i.e. removing the mount point at last.
Also, the current logic may not work with VM based containers as the
hypervisor may hold a reference on the mount point while we're trying to
remove them.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Use containers/storage to store images, pod sandboxes, and containers.
A pod sandbox's infrastructure container has the same ID as the pod to
which it belongs, and all containers also keep track of their pod's ID.
The container configuration that we build using the data in a
CreateContainerRequest is stored in the container's ContainerDirectory
and ContainerRunDirectory.
We catch SIGTERM and SIGINT, and when we receive either, we gracefully
exit the grpc loop. If we also think that there aren't any container
filesystems in use, we attempt to do a clean shutdown of the storage
driver.
The test harness now waits for ocid to exit before attempting to delete
the storage root directory.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
