Allow created containers to be killed#875
Allow created containers to be killed#875crosbymichael merged 1 commit intoopencontainers:masterfrom
Conversation
|
LGTM |
runtime.md
Outdated
|
|
||
| This operation MUST [generate an error](#errors) if it is not provided the container ID. | ||
| Attempting to send a signal to a container that is not running MUST have no effect on the container and MUST [generate an error](#errors). | ||
| Attempting to send a signal to a container that is not running or not created MUST have no effect on the container and MUST [generate an error](#errors). |
There was a problem hiding this comment.
I'd rather tie this more clearly to the already-well-defined state values. Something like:
Attempting to send a signal to a container that is neither [`created` nor `running`](#state) MUST have no effect…
That's pretty close to what you're suggesting, although it:
- Uses “neither”/“nor” instead of repeating “not”.
- Links to the “State” section for formal definitions of
createdandrunningstates. - Uses backticks to strengthen the “these are formally defined terms” semantics of
runningandcreated. - Lists
createdbeforerunning, since any given container that ends up inrunningwill always have passed throughcreatedearlier in its lifecycle, and no container can return tocreatedafter it has enteredrunning.
|
What's the use-case for killing a container that isn't running? What's the expected behavior? |
Getting ready to
The signal gets sent to the container process, same as in the |
|
While we're cleaning up the relationship between operations and container state, I think we can replace these two
And these two
|
Signed-off-by: Mrunal Patel <[email protected]>
|
Updated. |
|
LGTM |
|
@tianon Orchestrator could have a sequence where it is first creating a bunch of containers and then starting them. If there is a failure in the start sequence it could just kill the remaining created containers. |
|
LGTM |
5 participants
Signed-off-by: Mrunal Patel [email protected]