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.

Sign up for GitHub

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

runtime: Replace "process is stopped" with "process exits" #465

Merged
merged 1 commit into from
Jan 22, 2017
Merged

runtime: Replace "process is stopped" with "process exits" #465

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
11 changes: 6 additions & 5 deletions runtime.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,9 +15,10 @@ This MUST be unique across all containers on this host.
There is no requirement that it be unique across hosts.
* **`status`**: (string) is the runtime state of the container.
The value MAY be one of:
* `created`: the container has been created but the user-specified program has not yet been executed
* `running`: the container has been created and the user-specified program is running
* `stopped`: the container has been created and the user-specified program has been executed but is no longer running

* `created`: the container process has neither exited nor executed the user-specified program
* `running`: the container process has executed the user-specified program but has not exited
* `stopped`: the container process has exited
Copy link
Contributor

Choose a reason for hiding this comment

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

Why remove the container has been created phrase? I don't think that redundant, especially for the created status.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe the container process crashed during creation, in which case we're stopped before the container has been fully created. And see #507, which builds on this PR and adds creating. In the absence of a creating status (this PR before #507), I think we're created even before creation has finished.

Copy link
Member

Choose a reason for hiding this comment

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

It would be better to state that in the stopped state the container has ran the container's main process and it has exited leaving the container in the stopped state

Copy link
Member

Choose a reason for hiding this comment

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

If create fails the container should be destroyed and will be by the runtimes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It would be better to state that in the stopped state the container has ran the container's main process…

This is not necessarily true, since the container process may have died during creation or between creation and the start call.

If create fails the container should be destroyed and will be by the runtimes.

Agreed, but we need to define the status passed to any post-stop hooks, which run after the container process exits. That happens even if the container process dies during creation.


Additional values MAY be defined by the runtime, however, they MUST be used to represent new runtime states not defined above.
* **`pid`**: (int) is the ID of the container process, as seen by the host.
Expand Down Expand Up @@ -55,8 +56,8 @@ The lifecycle describes the timeline of events that happen from when a container
However, some actions might only be available based on the current state of the container (e.g. only available while it is started).
4. Runtime's [`start`](runtime.md#start) command is invoked with the unique identifier of the container.
The runtime MUST run the user-specified program, as specified by [`process`](config.md#process).
5. The container's process is stopped.
This MAY happen due to them erroring out, exiting, crashing or the runtime's [`kill`](runtime.md#kill) operation being invoked.
5. The container process exits.
This MAY happen due to erroring out, exiting, crashing or the runtime's [`kill`](runtime.md#kill) operation being invoked.
Copy link
Member

Choose a reason for hiding this comment

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

This is not correct as the runtime's kill command can sent non terminating signals.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is not correct as the runtime's kill command can sent non terminating signals.

I agree, but this MAY does not list all possible triggers nor does it require listed triggers to cause container exit. And it's the existing language and is orthogonal to the stopped → exited I'm focusing on here. Maybe file a new PR with your suggested wording?

6. Runtime's [`delete`](runtime.md#delete) command is invoked with the unique identifier of the container.
The container MUST be destroyed by undoing the steps performed during create phase (step 2).

Expand Down