Skip to content

runc: support multi-container delete and update runtime-spec #1299

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

Closed
yzewei wants to merge 1 commit into from
Closed

runc: support multi-container delete and update runtime-spec #1299

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
12 changes: 9 additions & 3 deletions runtime.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -73,7 +73,7 @@ The lifecycle describes the timeline of events that happen from when a container
If any `poststart` hook fails, the runtime MUST [generate an error](#errors), stop the container, and continue the lifecycle at step 12.
10. The container process exits.
This MAY happen due to erroring out, exiting, crashing or the runtime's [`kill`](runtime.md#kill) operation being invoked.
11. Runtime's [`delete`](runtime.md#delete) command is invoked with the unique identifier of the container.
11. Runtime's [`delete`](runtime.md#delete) command is invoked with one or more container IDs.
12. The container MUST be destroyed by undoing the steps performed during create phase (step 2).
13. The [`poststop` hooks](config.md#poststop) MUST be invoked by the runtime.
If any `poststop` hook fails, the runtime MUST [log a warning](#warnings), but the remaining hooks and lifecycle continue as if the hook had succeeded.
Expand All @@ -83,6 +83,10 @@ The lifecycle describes the timeline of events that happen from when a container
In cases where the specified operation generates an error, this specification does not mandate how, or even if, that error is returned or exposed to the user of an implementation.
Unless otherwise stated, generating an error MUST leave the state of the environment as if the operation were never attempted - modulo any possible trivial ancillary changes such as logging.

When multiple container IDs are provided to the delete operation, the runtime MUST attempt to delete each container independently.
If an error occurs for a specific container (e.g., container not stopped, container does not exist), the runtime MUST report that error for that container.
An error on one container MUST NOT prevent deletion attempts on the remaining containers.

## <a name="runtimeWarnings" />Warnings

In cases where the specified operation logs a warning, this specification does not mandate how, or even if, that warning is returned or exposed to the user of an implementation.
Expand Down Expand Up @@ -136,11 +140,13 @@ Attempting to send a signal to a container that is neither [`created` nor `runni
This operation MUST send the specified signal to the container process.

### <a name="runtimeDelete" />Delete
`delete <container-id>`
`delete <container-id> [<container-id> ...]`
Copy link
Member

@AkihiroSuda AkihiroSuda Oct 16, 2025

Choose a reason for hiding this comment

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

runtime-spec/runtime.md

Line 95 in 5610abd

Note: these operations are not specifying any command-line APIs, and the parameters are inputs for general operations.

I agree with @cyphar

This seems to be the scope of the runc's implementation details.


This operation MUST [generate an error](#errors) if it is not provided the container ID.
This operation MUST [generate an error](#errors) if it is not provided at least one container ID.
Attempting to `delete` a container that is not [`stopped`](#state) MUST have no effect on the container and MUST [generate an error](#errors).
When multiple container IDs are provided, the runtime MUST attempt to delete all specified containers and MUST report an error for each container individually if it cannot be deleted. An error on one container MUST NOT prevent deletion attempts on other containers.
Deleting a container MUST delete the resources that were created during the `create` step.
Resources associated with the container, but not created by this container, MUST NOT be deleted.
Note that resources associated with the container, but not created by this container, MUST NOT be deleted.
Once a container is deleted its ID MAY be used by a subsequent container.

Expand Down