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

Add lifecycle for containers #231

Merged
merged 1 commit into from
Dec 9, 2015
Merged

Add lifecycle for containers #231

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
34 changes: 18 additions & 16 deletions runtime.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,22 +34,24 @@ This is provided so that consumers can find the container's configuration and ro
```

## Lifecycle

### Create

Creates the container: file system, namespaces, cgroups, capabilities.

### Start (process)

Runs a process in a container.
Can be invoked several times.

### Stop (process)

Not sure we need that from runc cli.
Process is killed from the outside.

This event needs to be captured by runc to run onstop event handlers.
The lifecycle describes the timeline of events that happen from when a container is created to when it ceases to exist.

1. OCI compliant runtime is invoked by passing the bundle path as argument.
Copy link
Contributor

Choose a reason for hiding this comment

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

What is a runtime? To me, runtime seems to indicate higher level systems.

Copy link
Contributor

Choose a reason for hiding this comment

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

On Tue, Nov 17, 2015 at 05:37:56PM -0800, Vish Kannan wrote:

+1. OCI compliant runtime is invoked by passing the bundle path as
argument.

What is a runtime? To me, runtime seems to indicate higher level
systems.

It's “tools like runC”, see “compliant runtime” in 1 and #107. What
do you call those?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep, runtime means a OCI compliant runtime.

2. The container's runtime environment is created according to the configuration in config.json.
Any updates to config.json after container is running do not affect 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.

We probably need to mention runtime.json here too. I'm in favor of rolling it back into config.json, but we aren't there yet.

Copy link
Contributor

Choose a reason for hiding this comment

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

Previous discussion starting here (and I really miss the email-based workflow where previous discussions like that are linkable without having to find the right “Show outdated diff” button :p).

3. The container's state.json file is written to the filesystem under /run/opencontainer/<runtime>/containers/<id>/.
Copy link
Contributor

Choose a reason for hiding this comment

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

We should not specify the path here (just stop after “to the filesystem”). See @vbatts here in response to a comment on an outdated diff.

4. The prestart hooks are invoked by the runtime.
Copy link
Contributor

Choose a reason for hiding this comment

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

This step is subject to change based on namespaces pinning POC right? Shall we explicitly mention that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is a note at the bottom to this effect.

If any prestart hook fails, then the container is stopped and the lifecycle continues at step 8.
5. The user specified process is executed in the container.
6. The poststart hooks are invoked by the runtime.
If any poststart hook fails, then the container is stopped and the lifecycle continues at step 8.
7. Additional actions such as pausing the container, resuming the container or signaling the container may be performed using the runtime interface.
Copy link
Contributor

Choose a reason for hiding this comment

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

With ec85489 → bd549a2 you dropped “checkpointing the container”, but left in pause/resume/signalling. @vishh didn't call those out in his original comment, but they also seem like something we'd want to address after landing a simpler start/cleanup lifecycle. As it stands, this is the only reference to pausing in the spec, and it doesn't look detailed enough to be useful.

Copy link
Contributor

Choose a reason for hiding this comment

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

runtime interface --> runtime interfaces?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hqhq interface would support multiple operations so I think singular form is fine here.

Copy link
Contributor

Choose a reason for hiding this comment

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

I still think we want to drop pause/resume/signal until we have more clarity on how they will work. For more background here, especially around complications with shared state on Linux, see wking/oci-command-line-api#3. Alternatively, if we already have a clear idea of how these will work in the absence of /run/opencontainer, I'd appreciate some comments in the CLI-spec PR explaining what the CLI should look like.

The container could also error out or crash.
8. The container is destroyed by undoing the steps performed during create phase (step 2).
9. The poststop hooks are invoked by the runtime and errors, if any, are logged.
10. The state.json file associated with the container is removed and the return code of the container's user specified process is returned or logged.

Note: The lifecycle is a WIP and it will evolve as we have more use cases and more information on the viability of a separate create phase.

## Hooks

Expand Down