Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjust filesnames to match associated JSON #126

Closed
wants to merge 11 commits into from
8 changes: 5 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,11 @@ This project is where the [Open Container Initiative](http://www.opencontainers.
Table of Contents

- [Filesystem Bundle](bundle.md)
- [Container Configuration](config.md)
- [Linux Specific Configuration](config-linux.md)
- [Runtime and Lifecycle](runtime.md)
- [Host-independent Container Configuration](config.md)
- [Linux-specific Configuration](config-linux.md)
- [Host-specific Container Configuration](runtime.md)
- [Linux-specific Configuration](runtime-linux.md)
- [Runtime and Lifecycle](lifecycle.md)
- [Implementations](implementations.md)

## Use Cases
Expand Down
1 change: 1 addition & 0 deletions bundle.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,7 @@ The `runtime.json` file contains settings that are host specific such as memory
The goal is that the bundle can be moved as a unit to another machine and run the same application if `runtime.json` is removed or reconfigured.

The syntax and semantics for `config.json` are described in [this specification](config.md).
The syntax and semantics for `runtime.json` are described in [this specification](runtime.md).

A single `rootfs` directory MUST be in the same directory as the `config.json`.
The names of the directories may be arbitrary, but users should consider using conventional names as in the example below.
Expand Down
File renamed without changes.
2 changes: 1 addition & 1 deletion config-linux.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Linux-specific configuration
# Linux-specific, host-independent configuration

The Linux container specification uses various kernel features like namespaces,
cgroups, capabilities, LSM, and file system jails to fulfill the spec.
Expand Down
2 changes: 1 addition & 1 deletion config.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Configuration file
# Host-independent container configuration

The container's top-level directory MUST contain a configuration file called `config.json`.
For now the canonical schema is defined in [spec.go](spec.go) and [spec_linux.go](spec_linux.go), but this will be moved to a formal JSON schema over time.
Expand Down
13 changes: 13 additions & 0 deletions lifecycle-linux.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
# Linux-specific lifecycle notes

The [platform-independent lifecycle](lifecycle.md) has a few Linux-specific extensions.

## Start (process)

### File descriptors

By default, only the `stdin`, `stdout` and `stderr` file descriptors are kept open for the application by the runtime.

The runtime may pass additional file descriptors to the application to support features such as [socket activation](http://0pointer.de/blog/projects/socket-activated-containers.html).

Some of the file descriptors may be redirected to `/dev/null` even though they are open.
42 changes: 42 additions & 0 deletions lifecycle.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# Lifecycle

A typical lifecyle progresses like this:

1. There is no container or running application
2. A user tells the runtime to [create](#create) a container
3. The runtime creates the container
4. A user tells the runtime to [start](#start-process) an application
5. The runtime executes any [pre-start hooks](runtime.md#pre-start)
6. The runtime executes the application
7. The application is running
8. A user tells the runtime to [stop](#stop) an application
9. The runtime sends a termination signal to the application
10. The application exits
11. The runtime executes any [post-stop hooks](runtime.md#post-stop)
12. A user tells the runtime to [destroy](#destroy) the container
13. The runtime removes the container

With steps 8 and 9, the user is explicitly stopping the application
(via the runtime), but it's also possible that the application could
exit for other reasons. In that case we skip directly from 7 to 10.

## Create

Creates the container: file system, namespaces, cgroups, capabilities.

## Start (process)

Runs a process in a container. Can be invoked several times.
On Linux hosts, some information for this execution may come from outside the [`config.json`](config.md) and [`runtime.json`](runtime.md) specifications.
See [the Linux-specific notes](lifecycle-linux.md#start-process) for details.

## Stop (process)

Not sure we need that from runc cli. Process is killed from the outside.

This event needs to be captured by runc to run onstop event handlers.

## Destroy

Remove the container: unmount file systems, remove namespaces, etc.
This is the inverse of [create](#create).
195 changes: 0 additions & 195 deletions runtime-config-linux.md

This file was deleted.

54 changes: 0 additions & 54 deletions runtime-config.md

This file was deleted.

File renamed without changes.
Loading