-
Notifications
You must be signed in to change notification settings - Fork 553
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add initial pass at a cmd line spec #511
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,96 @@ | ||
# Runtime Command Line Interface | ||
|
||
This document specifies the command line syntax for runtime operations defined in the [Runtime and Lifecycle](runtime.md) specification. | ||
It is STRONGLY RECOMMENDED that implementations adhere to the command line definition defined below to ensure interoperability. | ||
This document will not duplicate the information/semantics specified in the [Runtime and Lifecycle](runtime.md) document, rather it just focuses on syntax of the command line. | ||
|
||
## Convention | ||
|
||
For the purpose of this document, the following syntactical conventions are used: | ||
|
||
* `[ ... ]` denotes an optional field | ||
* `< ... >` denotes a substitution field. | ||
The word(s), or phrase, within the `<>` describes the information to be passed-in. | ||
|
||
## General Format and Behavior | ||
|
||
The general format of all commands MUST be: | ||
``` | ||
runtime [global-options] action [action-specific-options] [arguments] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. #513 places limits on the option and action formats so runtimes can identify unrecognised actions as such. See wking/oci-command-line-api#8 for more discussion. |
||
``` | ||
|
||
Unknown options (global and action specific) MUST generate an error and exit with a non-zero exit code, without changing the state of the environment. | ||
|
||
Upon successful running of an action, the exit code MUST be zero. | ||
|
||
If there is an error during the running of an action, then: | ||
* the exit code MUST be non-zero | ||
* any error text MUST be displayed on stderr | ||
* the state of the environment SHOULD be the same as if the action was never attempted (modulo any possible trivial ancillary changes such as logging) | ||
|
||
### Global Options | ||
|
||
Global options are ones that apply to all actions. | ||
This specification doesn't define any global options. | ||
Implementation MAY define their own. | ||
|
||
### Action Specific Options | ||
|
||
All actions MUST support the `--help` action-specific-option, which: | ||
* MUST display some help text to stdout | ||
* MUST NOT perform the `action` itself | ||
* MUST have an exit code of zero if the help text is successfully displayed | ||
|
||
Implementations MAY define their own action-specific options. | ||
|
||
## Actions | ||
|
||
This section defines the actions defined by this specification. | ||
|
||
### State | ||
|
||
Format: `runtime [global-options] state [options] <container-id>` | ||
|
||
Options: None | ||
|
||
This action MUST display the state of the specific container to stdout. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. #513 has some wording around the expected encoding for the output from these commands. Background on this in wking/oci-command-line-api#2 and wking/oci-command-line-api#16. |
||
Unless otherwise specified by the user, the format of the state MUST be in JSON. | ||
|
||
See [Query State](runtime.md#query-state). | ||
|
||
### Create | ||
|
||
Format: `runtime [global-options] create [options] <container-id>` | ||
|
||
Options: | ||
* `-b <dir>`, `--bundle <dir>` The path to the root of the bundle directory. If not specified the default value MUST be the current working directory. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think we want to bother with short-form options in this spec. The goal is to provide a minimal, generic API for driving a compliant runtime (which the long-form gives us). Generic runtime-callers (like the compliance test suite) can use that long form, and leave runtimes free to pick whatever short-form abbreviations they like (if any). |
||
* `--console <path>` The PTY slave path for the newly created container. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We still need to figure out how we should deal with consoles in the spec. I'm personally still wondering what the semantics of consoles should be. /cc @wking There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that kind of thing would be in the runtime.md doc no? I tried really hard to keep this doc focused just on the syntax and not semantics, where possible. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm including whether or not the console options should even be a command-line option. Right now it feels wrong to me, especially since There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On Wed, Jul 06, 2016 at 07:16:56AM -0700, Doug Davis wrote:
I agree, and think it's not worth worrying about how terminal There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For now I tried to make this doc align with what |
||
* `--pid-file <path>` The file path into which the process ID is written. If not specified then a file MUST NOT be created. | ||
|
||
See [Create](runtime.md#create). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also relevant is the file-descriptor wording, which I brought over in #513 (see 50fd47a). I think it's also worth pointing out that (with the current runC approach) this command exits immediately after container-creation completes, with an exit code reflecting succesful (or not) creation. In the event that the standard streams (inherited by the container process) were not something persistent (like a pseudo-TTY), I'm not sure where that leaves the container process (probably setup for SIGPIPE and similar). |
||
|
||
### Start | ||
|
||
Format: `runtime [global-options] start [options] <container-id>` | ||
|
||
Options: None | ||
|
||
See [Start](runtime.md#start). | ||
|
||
### Kill | ||
|
||
Format: `runtime [global-options] kill [options] <container-id> <signal>` | ||
|
||
Options: None | ||
|
||
The `signal` MUST either be the signal's numerical value (e.g. `15`) or the signal's name (e.g. `SIGTERM`). | ||
|
||
See [Kill](runtime.md#kill). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
|
||
### Delete | ||
|
||
Format: `runtime [global-options] delete [options] <container-id>` | ||
|
||
Options: None | ||
|
||
See [Delete](runtime.md#delete). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You want a
Makefile
entry too, see #513's 4a25725.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done