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 (<dl>) would have nice default styling, but it's annoying to write raw HTML. And we would have needed something like: <dt name="bundle">Bundle</dt> <dd> A [directory structure](bundle.md) that is... </dd> 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 <wking@tremily.us>
This commit is contained in:
parent
d7df1b4f82
commit
18734986bc
|
@ -15,6 +15,7 @@ Table of Contents
|
||||||
- [Runtime and Lifecycle](runtime.md)
|
- [Runtime and Lifecycle](runtime.md)
|
||||||
- [Linux Specific Runtime](runtime-linux.md)
|
- [Linux Specific Runtime](runtime-linux.md)
|
||||||
- [Implementations](implementations.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).
|
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).
|
||||||
|
|
||||||
|
|
|
@ -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).
|
Loading…
Reference in New Issue