Eric Ernst 40316f688a qemu: no state to save if QEMU isn't running
On pod delete, we were looking to read files that we had just deleted. In particular,
stopSandbox for QEMU was called (we cleanup up vmpath), and then QEMU's
save function was called, which immediately checks for the PID file.

Let's only update the persist store for QEMU if QEMU is actually
running. This'll avoid Error messages being displayed when we are
stopping and deleting a sandbox:

```
level=error msg="Could not read qemu pid file"
```

I reviewed CLH, and it looks like it is already taking appropriate
action, so no changes needed.

Ideally we won't spend much time saving state to persist.json unless
there's an actual error during stop/delete/shutdown path, as the persist will
also be removed after the pod is removed. We may want to optimize this,
as currently we are doing a persist store when deleting each container
(after the sandbox is stopped, VM is killed), and when we stop the sandbox.
This'll require more rework... tracked in:
  https://github.com/kata-containers/kata-containers/issues/1181

Fixes: #1179

Signed-off-by: Eric Ernst <eric.g.ernst@gmail.com>
2021-01-13 18:30:46 +08:00
2020-10-06 17:54:13 -07:00
2020-11-26 10:11:36 -06:00
2020-10-18 00:40:16 +08:00
2020-10-06 17:54:13 -07:00
2017-12-06 23:01:13 -06:00
2020-06-27 20:16:53 -07:00
2020-06-25 11:19:12 +01:00
2020-10-19 06:18:08 +00:00
2020-10-18 00:43:15 +08:00

Kata Containers


Welcome to Kata Containers!

The purpose of this repository is to act as a "top level" site for the project. Specifically it is used:

Raising issues

This repository is used for raising issues:

  • That might affect multiple code repositories.

  • Where the raiser is unsure which repositories are affected.

Note:

  • If an issue affects only a single component, it should be raised in that components repository.

Kata Containers repositories

CI

The CI repository stores the Continuous Integration (CI) system configuration information.

Community

The Community repository is the first place to go if you want to use or contribute to the project.

Code Repositories

Kata Containers-developed components

Agent

The kata-agent runs inside the virtual machine and sets up the container environment.

KSM throttler

The kata-ksm-throttler is an optional utility that monitors containers and deduplicates memory to maximize container density on a host.

Runtime

The kata-runtime is usually invoked by a container manager and provides high-level verbs to manage containers.

Trace forwarder

The kata-trace-forwarder is a component only used when tracing the agent process.

Additional

Kernel

The hypervisor uses a Linux* kernel to boot the guest image.

Documentation

The docs directory holds documentation common to all code components.

Packaging

We use the packaging to create packages for the system components including rootfs and kernel images.

Test code

The tests repository hosts all test code except the unit testing code (which is kept in the same repository as the component it tests).

Utilities

OS builder

The osbuilder tool can create a rootfs and a "mini O/S" image. This image is used by the hypervisor to setup the environment before switching to the workload.

kata-agent-ctl

kata-agent-ctl is a low-level test tool for interacting with the agent.

Web content

The www.katacontainers.io repository contains all sources for the https://www.katacontainers.io site.

Credits

Kata Containers uses packagecloud for package hosting.

Languages
Rust 58%
Go 24.6%
Shell 10.1%
RPC 5.3%
Makefile 1%
Other 0.9%