This repository has been archived by the owner on May 12, 2021. It is now read-only.
cli: Stop the sandbox on a KILL #246
Comments
sboeuf
pushed a commit
to sboeuf/runtime-1
that referenced
this issue
Apr 23, 2018
The same way a caller of "kata-runtime kill 12345" expects the container 12345 to be killed, the same call to a container representing a sandbox should actually kill the sandbox, meaning it would be stopped after the container has been killed. This way, the caller knows the VM is stopped after kill returns. This is an issue raised by Openshift and Kubernetes tests. They call into delete way after the call to kill has been submitted, and in the meantime they kill all processes related to the container, meaning they do kill the VM before we could do it ourselves. In this case, the delete responsible of stopping the VM comes too late and it returns an error when trying to destroy the sandbox while trying to communicate with the agent since the VM is not here anymore. This commit addresses this issue by letting "kill" calling into StopSandbox() if the command relates to a sandbox instead of a simple container. Fixes kata-containers#246 Signed-off-by: Sebastien Boeuf <[email protected]>
sboeuf
pushed a commit
to sboeuf/runtime-1
that referenced
this issue
Apr 23, 2018
The same way a caller of "kata-runtime kill 12345" expects the container 12345 to be killed, the same call to a container representing a sandbox should actually kill the sandbox, meaning it would be stopped after the container has been killed. This way, the caller knows the VM is stopped after kill returns. This is an issue raised by Openshift and Kubernetes tests. They call into delete way after the call to kill has been submitted, and in the meantime they kill all processes related to the container, meaning they do kill the VM before we could do it ourselves. In this case, the delete responsible of stopping the VM comes too late and it returns an error when trying to destroy the sandbox while trying to communicate with the agent since the VM is not here anymore. This commit addresses this issue by letting "kill" calling into StopSandbox() if the command relates to a sandbox instead of a simple container. Fixes kata-containers#246 Signed-off-by: Sebastien Boeuf <[email protected]>
sboeuf
pushed a commit
to sboeuf/runtime-1
that referenced
this issue
Apr 24, 2018
The same way a caller of "kata-runtime kill 12345" expects the container 12345 to be killed, the same call to a container representing a sandbox should actually kill the sandbox, meaning it would be stopped after the container has been killed. This way, the caller knows the VM is stopped after kill returns. This is an issue raised by Openshift and Kubernetes tests. They call into delete way after the call to kill has been submitted, and in the meantime they kill all processes related to the container, meaning they do kill the VM before we could do it ourselves. In this case, the delete responsible of stopping the VM comes too late and it returns an error when trying to destroy the sandbox while trying to communicate with the agent since the VM is not here anymore. This commit addresses this issue by letting "kill" calling into StopSandbox() if the command relates to a sandbox instead of a simple container. Fixes kata-containers#246 Signed-off-by: Sebastien Boeuf <[email protected]>
sboeuf
pushed a commit
to sboeuf/runtime-1
that referenced
this issue
Apr 25, 2018
The same way a caller of "kata-runtime kill 12345" expects the container 12345 to be killed, the same call to a container representing a sandbox should actually kill the sandbox, meaning it would be stopped after the container has been killed. This way, the caller knows the VM is stopped after kill returns. This is an issue raised by Openshift and Kubernetes tests. They call into delete way after the call to kill has been submitted, and in the meantime they kill all processes related to the container, meaning they do kill the VM before we could do it ourselves. In this case, the delete responsible of stopping the VM comes too late and it returns an error when trying to destroy the sandbox while trying to communicate with the agent since the VM is not here anymore. This commit addresses this issue by letting "kill" call into StopSandbox() if the command relates to a sandbox instead of a simple container. Fixes kata-containers#246 Signed-off-by: Sebastien Boeuf <[email protected]>
zklei
pushed a commit
to zklei/runtime
that referenced
this issue
Jun 13, 2019
grpc: implement pause and resume commands
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The same way a caller of the
kata-runtime kill 12345expect the container12345to be killed, the same call to a container representing a sandbox should actually kill the sandbox, which means it would be stopped after the container has been killed.This way, the caller knows the VM is stopped after
killreturns. This is an issue raised by the following issue: #197.Openshiftandk8scall intodeleteway after the call tokillhas been submitted, and in the meantime they kill all processes related to the container, meaning they do kill the VM before we could do it ourselves. In this case, thedeleteresponsible of stopping the VM comes too late and it returns an error when trying to destroy the sandbox while trying to communicate with the agent since the VM is not here anymore.The text was updated successfully, but these errors were encountered: