config: Single, unified config file

Reverting 7232e4b (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1].  The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec.  Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.

There have been a number of additional changes since #88, so this
isn't a pure Git reversion.  Besides copy-pasting and the associated
link-target updates, I've:

* Restored path -> destination, now that the mount type contains both
  source and target paths again.  I'd prefer 'target' to 'destination'
  to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
  (possibly due to Windows using 'target' for the source?).

* Restored the Windows mount example to its pre-7232e4b1 content.

* Removed required mounts from the config example (requirements landed
  in 3848a23, config-linux: specify the default devices/filesystems
  available, 2015-09-09, #164), because specifying those mounts in the
  config is now redundant.

* Used headers (vs. bold paragraphs) to set off mount examples so we
  get link anchors in the rendered Markdown.

* Replaced references to runtime.json with references to config.json.

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
     Subject: Single, unified config file (i.e. rolling back specs#88)
     Date: Wed, 4 Nov 2015 09:53:20 -0800
     Message-ID: <[email protected]>

Signed-off-by: W. Trevor King <[email protected]>

Makefile

@@ -12,8 +12,6 @@ DOC_FILES := \
  runtime-linux.md \
  config.md \
  config-linux.md \
- runtime-config.md \
- runtime-config-linux.md \
  glossary.md
 EPOCH_TEST_COMMIT := 041eb73d2e0391463894c04c8ac938036143eba3
 

README.md

@@ -9,10 +9,8 @@ Table of Contents
 - [Specification Style](style.md)
 - [Filesystem Bundle](bundle.md)
 - Configuration
- - [Container Configuration](config.md)
- - [Container Configuration (Linux-specific)](config-linux.md)
- - [Runtime Configuration](runtime-config.md)
- - [Runtime Configuration (Linux-specific)](runtime-config-linux.md)
+ - [General](config.md)
+ - [Linux-specific](config-linux.md)
 - [Runtime and Lifecycle](runtime.md)
  - [Linux Specific Runtime](runtime-linux.md)
 - [Implementations](implementations.md)
@@ -27,12 +25,12 @@ To provide context for users the following section gives example use cases for e
 #### Application Bundle Builders
 
 Application bundle builders can create a [bundle](bundle.md) directory that includes all of the files required for launching an application as a container.
-The bundle contains OCI [configuration files](config.md) where the builder can specify host-independent details such as [which executable to launch](config.md#process-configuration) and host-specific settings such as [mount](runtime-config.md#mount-configuration) locations, [hook](runtime-config.md#hooks) paths, Linux [namespaces](runtime-config-linux.md#namespaces) and [cgroups](runtime-config-linux.md#control-groups).
+The bundle contains an OCI [configuration file](config.md) where the builder can specify host-independent details such as [which executable to launch](config.md#process-configuration) and host-specific settings such as [mount](config.md#mounts) locations, [hook](config.md#hooks) paths, Linux [namespaces](config-linux.md#namespaces) and [cgroups](config-linux.md#control-groups).
 Because the configuration includes host-specific settings, application bundle directories copied between two hosts may require configuration adjustments.
 
 #### Hook Developers
 
-[Hook](runtime-config.md#hooks) developers can extend the functionality of an OCI-compliant runtime by hooking into a container's lifecycle with an external application.
+[Hook](config.md#hooks) developers can extend the functionality of an OCI-compliant runtime by hooking into a container's lifecycle with an external application.
 Example use cases include sophisticated network configuration, volume garbage collection, etc.
 
 #### Runtime Developers

ROADMAP.md

@@ -17,13 +17,6 @@ Although OCI doesn't define a transport method we should have a cryptographic di
 
 *Owner:* philips
 
-### Review the need for runtime.json (Target release: v0.3.0)
-
-There are some discussions about having `runtime.json` being optional for containers and specifying defaults.
-Runtimes would use this standard set of defaults for containers and `runtime.json` would provide overrides for fine tuning of these extra host or platform specific settings.
-
-*Owner:* mrunalp
-
 ### Define Container Lifecycle
 
 Containers have a lifecycle and being able to identify and document the lifecycle of a container is very helpful for implementations of the spec.

bundle.md

@@ -8,23 +8,17 @@ See also [OS X application bundles](http:https://en.wikipedia.org/wiki/Bundle_%28OS_X%
 The definition of a bundle is only concerned with how a container, and its configuration data, are stored on a local file system so that it can be consumed by a compliant runtime.
 
 A Standard Container bundle contains all the information needed to load and run a container.
-This includes the following three artifacts which MUST all reside in the same directory on the local filesystem:
+This includes the following artifacts which MUST all reside in the same directory on the local filesystem:
 
-1. `config.json` : contains host-independent configuration data.
-This REQUIRED file, which MUST be named `config.json`, contains settings that are host-independent and application-specific such as security permissions, environment variables and arguments.
+1. `config.json` : contains configuration data.
+This REQUIRED file, which MUST be named `config.json`.
 When the bundle is packaged up for distribution, this file MUST be included.
 See [`config.json`](config.md) for more details.
 
-2. `runtime.json` : contains host-specific configuration data.
-This REQUIRED file, which MUST be named `runtime.json`, contains settings that are host-specific such as mount sources and hooks.
-The goal is that the bundle can be moved as a unit to another runtime and run the same application once a host-specific `runtime.json` is defined.
-When the bundle is packaged up for distribution, this file MUST NOT be included.
-See [`runtime.json`](runtime-config.md) for more details.
-
-3. A directory representing the root filesystem of the container.
+2. A directory representing the root filesystem of the container.
 While the name of this REQUIRED directory may be arbitrary, users should consider using a conventional name, such as `rootfs`.
 When the bundle is packaged up for distribution, this directory MUST be included.
 This directory MUST be referenced from within the `config.json` file.
 
-While these three artifacts MUST all be present in a single directory on the local filesystem, that directory itself is not part of the bundle.
+While these artifacts MUST all be present in a single directory on the local filesystem, that directory itself is not part of the bundle.
 In other words, a tar archive of a *bundle* will have these artifacts at the root of the archive, not nested within a top-level directory.