Add OCI Runtime Abstract #691
Conversation
crosbymichael
force-pushed
the
abstract
branch
from
0a21c74 to
a716c17
Compare
|
LGTM |
spec.md
Outdated
| The OCI Runtime Specification aims to specify the inputs and outputs for running containers on various platforms. | ||
|
|
||
| A container's input or configuration is specified as the `config.json` for the supported platforms and details fields that enable containers to run on that platform. | ||
| It contains host specific information for the creation of a container. |
There was a problem hiding this comment.
I think you want “host specific” → “host-specific”, although master has inconsistent hyphenation for this.
spec.md
Outdated
|
|
||
| The OCI Runtime Specification aims to specify the inputs and outputs for running containers on various platforms. | ||
|
|
||
| A container's input or configuration is specified as the `config.json` for the supported platforms and details fields that enable containers to run on that platform. |
There was a problem hiding this comment.
You have “on various platforms” in the previous paragraph, so I don't think you need “for the supported platforms” here. Maybe just echo the current configuration description?
A container's input is a configuration which contains metadata necessary to implement standard operations against the container. This includes the process to run, environment variables to inject, sandboxing features to use, etc.
spec.md
Outdated
| A container's input or configuration is specified as the `config.json` for the supported platforms and details fields that enable containers to run on that platform. | ||
| It contains host specific information for the creation of a container. | ||
|
|
||
| The outputs of a container are defined as both actions that can be performed on a container after it has been created and the environment details that the container provides to applications running inside of it. |
There was a problem hiding this comment.
These don't sound like “the outputs of a container” to me. Actions are more like additional inputs. The container environment is more of a runtime output, and that's probably what you're trying to focus on here. I'd consider container output to be things like filesystem alterations which persist after container exit (e.g. simulation results written to a bind-mounted volume). And containers which host services don't fit cleanly into the the idea of “container output” at all. Maybe de-emphasize input/output and instead sketch the configuration, actions, and lifecycle in a few sentences each? Something like:
Containers are configured with metadata necessary to implement standard operations against the container. This includes the process to run, environment variables to inject, sandboxing features to use, etc. Runtimes create containers from that configuration, and several operations are defined to manage the container over its lifecycle.
|
I don't really like the "input and outputs" description either. I'd prefer if we instead emphasised that the runtime specification defines the execution environment configuration and lifecycle management of containers. There are inputs and outputs involved, but the key point is that we're standardising the lifecycle and the configuration of container runtimes. |
Closes opencontainers#506 Signed-off-by: Michael Crosby <[email protected]>
crosbymichael
force-pushed
the
abstract
branch
from
a716c17 to
b81c09c
Compare
|
@cyphar updated based on feedback |
|
lgtm |
|
LGTM |
1 similar comment
|
LGTM |
Closes #506
Signed-off-by: Michael Crosby [email protected]