Uh oh!
There was an error while loading. Please reload this page.
Allow created containers to be killed - #875
Conversation
| 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.
tianon
commented
Jun 23, 2017
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 |
wking
commented
Jun 23, 2017
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 <mrunalp@gmail.com>
mrunalp
commented
Jun 23, 2017
Updated. |
mrunalp
commented
Jun 23, 2017
@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. |
Signed-off-by: Mrunal Patel mrunalp@gmail.com