From c1e3515cde85ad02f7c3ed9604c39ccac591c9b6 Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Tue, 11 Aug 2015 10:15:20 -0700 Subject: [PATCH] glossary: Provide a quick overview of important terms And link them to the more detailed specification. Subsection titles for the entries will be obnoxiously spacious, but the other alternatives seem worse: a. An HTML definition list (
) would have nice default styling, but it's annoying to write raw HTML. And we would have needed something like:
Bundle
A [directory structure](bundle.md) that is...
to get Markdown-style links in the defintion itself. b. A Markdown list (* ...) would have reasonable default styling, but there's no Markdown syntax for adding anchors to the entries. And a glossary is much less useful if you can't link to a specific entry. Signed-off-by: W. Trevor King --- README.md | 1 + glossary.md | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+) create mode 100644 glossary.md diff --git a/README.md b/README.md index 5cf3e3400..e838b0188 100644 --- a/README.md +++ b/README.md @@ -15,6 +15,7 @@ Table of Contents - [Runtime and Lifecycle](runtime.md) - [Linux Specific Runtime](runtime-linux.md) - [Implementations](implementations.md) +- [Glossary](glossary.md) In the specifications in the above table of contents, the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119) (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997). diff --git a/glossary.md b/glossary.md new file mode 100644 index 000000000..c85362134 --- /dev/null +++ b/glossary.md @@ -0,0 +1,19 @@ +# Glossary + +## Bundle + +A [directory structure](bundle.md) that is written ahead of time, distributed, and used to seed the runtime for creating a [container](#container) and launching a process within it. + +## Configuration + +The [`config.json`](config.md) and [`runtime.json`](runtime-config.md) files in a [bundle](#bundle) which define the intended [container](#container) and container process. + +## Container + +An environment for executing processes with configurable isolation and resource limitations. +For example, namespaces, resource limits, mounts, etc. + +## Runtime + +An implementation of this specification. +It reads the [configuration files](#configuration) from a [bundle](#bundle), uses that information to create a [container](#container), launches a process inside the container, and performs other [lifecycle actions](runtime.md).