Skip to content
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

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,7 @@ DOC_FILES := \
bundle.md \
runtime.md \
runtime-linux.md \
cmd.md \
config.md \
config-linux.md \
config-solaris.md \
Expand Down
1 change: 1 addition & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@ Table of Contents
- Runtime and Lifecycle
- [General Runtime and Lifecycle](runtime.md)
- [Linux-specific Runtime and Lifecycle](runtime-linux.md)
- [Runtime Command Line Interface](cmd.md)
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

- Configuration
- [General Configuration](config.md)
- [Linux-specific Configuration](config-linux.md)
Expand Down
96 changes: 96 additions & 0 deletions cmd.md
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]
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Member

Choose a reason for hiding this comment

The 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

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Member

@cyphar cyphar Jul 6, 2016

Choose a reason for hiding this comment

The 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 terminal is in the config. Once we fix how we do path resolution, --console will be intimately related to the mountpoints of the container.

Copy link
Contributor

Choose a reason for hiding this comment

The 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:

+* --console <path> The PTY slave path for the newly created container.

I think that kind of thing would be in the runtime.md doc no?

I agree, and think it's not worth worrying about how terminal
information fits into the API before we have a clearer non-API spec
around what the setting means or have punted it from the non-API spec
[1](which is why wking/oci-command-line-api does not talk about
process.terminal-related stuff).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now I tried to make this doc align with what runc does so at least we're consistent. If we decide to change runc then that PR can cover both the code and this doc.

* `--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).
Copy link
Contributor

Choose a reason for hiding this comment

The 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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this needs more wording around allowed signals, since Windows does not support POSIX signals. I have some in #513 (see 2424618).


### Delete

Format: `runtime [global-options] delete [options] <container-id>`

Options: None

See [Delete](runtime.md#delete).