*: Remove "bundle" and go straight to config.json

Some history behind bundle requirements:

* 77d44b1 (Update runtime.md, 2015-06-16) lands the initial reference
  to a root filesystem, requiring a relative path.  It also lands the
  "bundle" construct, which at this point includes content
  directories, signatures, and the configuration file.  The content
  directories "at least" include the root filesystem.

* 5d2eb18 (*: re-org the spec, 2015-06-24) shifts the bundle docs to
  bundle.md and demotes signatures to "other related content".

* 91f5ad7 (bundle.md: various updates to latest spec, 2015-07-02,
  opencontainers#55) finishes the signature demotion and strengthens the
  root-inclusion requirement with another "must include".

* 7232e4b (specs: introduce the concept of a runtime.json,
  2015-07-30, opencontainers#88) split out runtime.json, required the root directory
  to exist at `rootfs`, and dropped most references to "content
  directories".

* 106ec2d (Cleanup bundle.md, 2015-10-02, opencontainers#210) kept the requirement
  for a rootfs directory in the bundle root, but relaxed the name
  requirement to allow other single-component names
  (e.g. `my-rootfs`).  Dropped the last reference to "content
  directories".

* cb2da54 (config: Single, unified config file, 2015-12-28, opencontainers#284)
  rolled runtime.json back into config.json.

* b2e9154 (Remove requirement for rootfs path to be relative,
  2016-04-22, opencontainers#394) allowed absolute paths for root.path and removed
  some "same directory" language while leaving other "same directory"
  language.

I think the root filesystem should be optional [1], but even folks who
disagree on that point have come to the conclusion that it doesn't
need to be in the bundle [2].  opencontainers#394 seems partially unfinished, but I
think the intention was clear.  Once you relax the "bundle must
contain the root filesystem" requirement, the only thing that the
bundle must contain is config.json.  It doesn't seem to be worth the
trouble to name a "bundle" construct if its only meaning is "the
directory that holds config.json", so this commit removes all
remaining references to the term "bundle".

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/6ZKMNWujDhU
     Subject: Dropping the rootfs requirement and restoring arbitrary bundle content
     Date: Wed, 26 Aug 2015 12:54:47 -0700
     Message-ID: <[email protected]>
[2]: opencontainers#389 (comment)

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

Makefile

@@ -11,7 +11,6 @@ DOC_FILES := \
 	ROADMAP.md \
 	implementations.md \
 	project.md \
-	bundle.md \
 	runtime.md \
 	runtime-linux.md \
 	config.md \

README.md

@@ -12,7 +12,6 @@ Table of Contents
   - [Roadmap](ROADMAP.md)
   - [Implementations](implementations.md)
   - [project](project.md)
-- [Filesystem Bundle](bundle.md)
 - Runtime and Lifecycle
   - [General Runtime and Lifecycle](runtime.md)
   - [Linux-specific Runtime and Lifecycle](runtime-linux.md)
@@ -31,11 +30,11 @@ An implementation that satisfies all the MUST or REQUIRED and all the SHOULD req
 
 To provide context for users the following section gives example use cases for each part of the spec.
 
-#### Application Bundle Builders
+#### Application Publishers
 
-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 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.
+Application publishers distribute OCI [configuration files](config.md) and related resources (for example, [referenced filesystems](config.md#root-configuration) for launching an application as a [container](glossary.md#container).
+The publisher 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, configurations copied between two hosts may require local adjustments.
 
 #### Hook Developers
 
@@ -44,7 +43,7 @@ Example use cases include sophisticated network configuration, volume garbage co
 
 #### Runtime Developers
 
-Runtime developers can build runtime implementations that run OCI-compliant bundles and container configuration, containing low-level OS and host specific details, on a particular platform.
+Runtime developers can build runtime implementations that perform [operations](runtime.md#operations) on [containers](glossary.md#container) on a particular platform.
 
 # Releases
 

config.md

@@ -10,7 +10,7 @@ Below is a detailed description of each field defined in the configuration forma
 
 ## Specification version
 
-* **`ociVersion`** (string, required) MUST be in [SemVer v2.0.0](http://semver.org/spec/v2.0.0.html) format and specifies the version of the OpenContainer specification with which the bundle complies.
+* **`ociVersion`** (string, required) MUST be in [SemVer v2.0.0](http://semver.org/spec/v2.0.0.html) format and specifies the version of the OpenContainer specification with which the configuration complies.
 The OpenContainer spec follows semantic versioning and retains forward and backward compatibility within major versions.
 For example, if an implementation is compliant with version 1.0.1 of the spec, it is compatible with the complete 1.x series.
 NOTE that there is no guarantee for forward or backward compatibility for version 0.x.
@@ -180,7 +180,7 @@ _Note: For Solaris, uid and gid specify the uid and gid of the process inside th
 
 ## Hostname
 
-* **`hostname`** (string, optional) as it is accessible to processes running inside.  On Linux, you can only set this if your bundle creates a new [UTS namespace][uts-namespace].
+* **`hostname`** (string, optional) as it is accessible to processes running inside.  On Linux, you can only set this if your configuration creates a new [UTS namespace][uts-namespace].
 
 ### Example
 

glossary.md

@@ -1,12 +1,8 @@
 # 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) file in a [bundle](#bundle) which defines the intended [container](#container) and container process.
+The [`config.json`](config.md) file which defines the intended [container](#container) and container process.
 
 ## Container
 
@@ -24,7 +20,7 @@ All configuration [JSON][] MUST be encoded in [UTF-8][].
 ## 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).
+It performs [operations](runtime.md#operations) on [containers](#container).
 
 ## Runtime namespace
 

implementations.md

@@ -14,5 +14,5 @@ If you know of any associated projects that are not listed here, please file a p
 ## Testing & Tools
 
 * [kunalkushwaha/octool](https://github.com/kunalkushwaha/octool) - A config linter and validator.
-* [opencontainers/ocitools](https://github.com/opencontainers/ocitools) - A config generator and runtime/bundle testing framework.
+* [opencontainers/ocitools](https://github.com/opencontainers/ocitools) - A config generator and runtime/configuration testing framework.
 * [huawei-openlab/oct](https://github.com/huawei-openlab/oct) - Open Container Testing framework for OCI configuration and runtime

principles.md

@@ -27,15 +27,15 @@ They are started in the same way whether they contain a postgres database, a php
 ## 3. Infrastructure-agnostic
 
 Standard Containers are INFRASTRUCTURE-AGNOSTIC: they can be run in any OCI supported infrastructure.
-For example, a standard container can be bundled on a laptop, uploaded to cloud storage, downloaded, run and snapshotted by a build server at a fiber hotel in Virginia, uploaded to 10 staging servers in a home-made private cloud cluster, then sent to 30 production instances across 3 public cloud regions.
+For example, a standard container can be packaged on a laptop, uploaded to cloud storage, downloaded, run and snapshotted by a build server at a fiber hotel in Virginia, uploaded to 10 staging servers in a home-made private cloud cluster, then sent to 30 production instances across 3 public cloud regions.
 
 ## 4. Designed for automation
 
 Standard Containers are DESIGNED FOR AUTOMATION: because they offer the same standard operations regardless of content and infrastructure, Standard Containers, are extremely well-suited for automation.
 In fact, you could say automation is their secret weapon.
 
 Many things that once required time-consuming and error-prone human effort can now be programmed.
-Before Standard Containers, by the time a software component ran in production, it had been individually built, configured, bundled, documented, patched, vendored, templated, tweaked and instrumented by 10 different people on 10 different computers.
+Before Standard Containers, by the time a software component ran in production, it had been individually built, configured, packaged, documented, patched, vendored, templated, tweaked and instrumented by 10 different people on 10 different computers.
 Builds failed, libraries conflicted, mirrors crashed, post-it notes were lost, logs were misplaced, cluster updates were half-broken.
 The process was slow, inefficient and cost a fortune - and was entirely different depending on the language and infrastructure provider.
 

runtime.md

@@ -16,7 +16,7 @@ There is no requirement that it be unique across hosts.
 The ID is provided in the state because hooks will be executed with the state as the payload.
 This allows the hooks to perform cleanup and teardown logic after the runtime destroys its own state.
 * **`pid`**: (int) is the ID of the main process within the container, as seen by the host.
-* **`bundlePath`**: (string) is the absolute path to the container's bundle directory.
+* **`configPath`**: (string) is the absolute path to the container's [configuration](config.md).
 This is provided so that consumers can find the container's configuration and root filesystem on the host.
 
 When serialized in JSON, the format MUST adhere to the following pattern:
@@ -26,7 +26,7 @@ When serialized in JSON, the format MUST adhere to the following pattern:
     "ociVersion": "0.2.0",
     "id": "oci-container1",
     "pid": 4422,
-    "bundlePath": "/containers/redis"
+    "configPath": "/containers/redis/config.json"
 }
 ```
 
@@ -35,7 +35,7 @@ See [Query State](#query-state) for information on retrieving the state of a con
 ## Lifecycle
 The lifecycle describes the timeline of events that happen from when a container is created to when it ceases to exist.
 
-1. OCI compliant runtime is invoked with a reference to the location of the bundle.
+1. OCI compliant runtime is invoked with a reference to the [configuration](config.md).
    How this reference is passed to the runtime is an implementation detail.
 2. The container's runtime environment MUST be created according to the configuration in [`config.json`](config.md).
    Any updates to `config.json` after container is running MUST not affect the container.
@@ -71,11 +71,10 @@ In particular, the state MUST be serialized as JSON.
 
 ### Start
 
-`start <container-id> <path-to-bundle>`
+`start <container-id> <path-to-configuration>`
 
-This operation MUST generate an error if it is not provided a path to the bundle and the container ID to associate with the container.
+This operation MUST generate an error if it is not provided a path to the [configuration](config.md) and the container ID to associate with the container.
 If the ID provided is not unique across all containers within the scope of the runtime, or is not valid in any other way, the implementation MUST generate an error.
-Using the data in `config.json`, that are in the bundle's directory, this operation MUST create a new container.
 This includes creating the relevant namespaces, resource limits, etc and configuring the appropriate capabilities for the container.
 A new process within the scope of the container MUST be created as specified by the `config.json` file otherwise an error MUST be generated.
 

specs-go/state.go

@@ -8,6 +8,6 @@ type State struct {
 	ID string `json:"id"`
 	// Pid is the process id for the container's main process.
 	Pid int `json:"pid"`
-	// BundlePath is the path to the container's bundle directory.
-	BundlePath string `json:"bundlePath"`
+	// ConfigPath is the path to the container's configuration.
+	ConfigPath string `json:"configPath"`
 }