Skip to content

Commit

Permalink
config: Single, unified config file
Browse files Browse the repository at this point in the history
Reverting 7232e4b (specs: introduce the concept of a runtime.json,
2015-07-30, opencontainers#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 opencontainers#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, opencontainers#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]>
  • Loading branch information
wking committed Dec 28, 2015
1 parent 2fd5ad6 commit 92a8686
Show file tree
Hide file tree
Showing 14 changed files with 941 additions and 1,028 deletions.
4 changes: 1 addition & 3 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
6 changes: 2 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down
7 changes: 0 additions & 7 deletions ROADMAP.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
16 changes: 5 additions & 11 deletions bundle.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Loading

0 comments on commit 92a8686

Please sign in to comment.