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: <20151104175320.GC24652@odin.tremily.us>

Signed-off-by: W. Trevor King <wking@tremily.us>

Makefile

@@ -10,9 +10,7 @@ DOC_FILES := \
 	runtime.md \
 	runtime-linux.md \
 	config.md \
-	config-linux.md \
-	runtime-config.md \
-	runtime-config-linux.md
+	config-linux.md
 
 docs: pdf html
 

README.md

@@ -8,10 +8,8 @@ Table of Contents
 - [Container Principles](principles.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)

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
-
-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:*
-
 ### 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://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 filesytem, that directory itself is not part of the bundle.
+While these artifacts MUST all be present in a single directory on the local filesytem, 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.