Design an API for container runtime

[mokuki082]

Design an API for create/start/delete/kill/stat for containers.

Take into consideration that:

• Image building should be separated from this API. The creation of containers is a staged process and we want to make it modular.
• We shouldn't assume that we can have a config.json file in the filesystem from this API. The container runtime spec should be feed to the API.

[mokuki082]

Runc actually makes a lot of assumptions on the filesystem. It saves the container information at /run/runc if the container is created by root user, and a custom location otherwise. There are also other dependencies such as unix socket location (which seems to be relied heavily by docker and runc), rootfs, config path, not mentioning one of the underlying technology: cgroups relies on a virtual fs as its API. Runc already has the config file parser set up, is it really worth it to go through the hassle of serialising the entire config file for the sake of not interacting with the filesystem?

[mokuki082]

According to OCI Runtime Operations Specification, to have the bare minimum container runtime we need the following operations:

Notation: API-name(<arg1>, <arg2>...): <return-value>

• Query state
  • Minimal requirement: state(container-id): (State, error)
  • State contains:
  • ociVersion
  • id
  • status (creating, created, running, stopped)
  • pid (id of container process seen by host)
  • bundle
  • annotations (key-value, optional)
• Create
  • Minimal requirement: create(container-id, bundle-path): error
  • bundle contains config.json and the container filesystem.
  • All properties in config.json are applied except process.
  • process.args MUST NOT be applied until triggered by start
  • Remaining process properties MAY be applied.
  • Changes to config.json after this operation will not effect the container.
  • Runtimes MUST create symlinks if the source file exists after processing mounts like this
• Start
  • Minimal requirement: start(container-id): error
  • This operation MUST run the user-specified program as specified in process.
• Kill
  • Minimal requriements: kill(container-id, Signal): error
  • MUST send the specified signal to the container process.
• Delete
  • Minimal requirements: delete(container-id): error
  • Attempting to delete a container that is not stopped MUST generate an error.

[mokuki082]

Closing this as we are utilising RunC as a whole, hence the API would be the same as RunC's commands.