glossary: Provide a quick overview of important terms

wking · wking · commit 18734986bc9e · 2015-12-23T09:27:30.000-08:00
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 (&lt;dl&gt;) would have nice default styling, but
   it's annoying to write raw HTML.  And we would have needed
   something like:

     &lt;dt name="bundle"&gt;Bundle&lt;/dt&gt;
     &lt;dd&gt;

     A [directory structure](bundle.md) that is...

     &lt;/dd&gt;

   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 &lt;wking@tremily.us&gt;
diff --git 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
@@ -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, and mounts are all part of the container environment.
+
+## 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).
