Skip to content
Merged
Changes from all commits
Commits
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
36 changes: 27 additions & 9 deletions ROADMAP.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,12 +17,12 @@ Although OCI doesn't define a transport method we should have a cryptographic di

*Owner:* philips

### Review the need for runtime.json
### Review the need for runtime.json (Target release: v0.3.0)

There are some discussions about having `runtime.json` being optional for containers and specifying defaults.
Runtimes would use this standard set of defaults for containers and `runtime.json` would provide overrides for fine tuning of these extra host or platform specific settings.

*Owner:*
*Owner:* mrunalp

### Define Container Lifecycle

Expand All @@ -31,38 +31,48 @@ The lifecycle events of a container also help identify areas to implement hooks

*Owner:* mrunalp

### Define Standard Container Actions
### Define Standard Container Actions (Target release: v0.3.0)

Define what type of actions a runtime can perform on a container without imposing hardships on authors of platforms that do not support advanced options.

*Owner:*
*Owner:* duglin

### Clarify rootfs requirement in base spec

Is the rootfs needed or should it just be expected in the bundle without having a field in the spec?

Resolution: keep it as is - user definable
Submit as a different PR
For reference: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/6ZKMNWujDhU

*Owner:*

### Container Definition

Define what a software container is and its attributes in a cross platform way.

*Owner:*
Could be solved by lifecycle/ops and create/start split discussions

*Owner:* vishh & duglin

### Live Container Updates

Should we allow dynamic container updates to runtime options?

*Owner:* vishh
Proposal: make it an optional feature

*Owner:* hqhq (was vishh) robdolinms, bcorrie

### Protobuf Config

We currently have only one language binding for the spec and that is Go.
If we change the specs format in the respository to be something like protobuf then the generation for multiple language bindings become effortless.

Not going to do it
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 my wording verbatim.

Copy link
Contributor

Choose a reason for hiding this comment

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

On Wed, Jan 13, 2016 at 11:24:14AM -0800, Vincent Batts wrote:

Protobuf Config

We currently have only one language binding for the spec and that is Go.
If we change the specs format in the respository to be something like protobuf then the generation for multiple language bindings become effortless.

+Not going to do it

This is my wording verbatim.

So close #185 with some notes on why? I'm fine with closing that
door, but I expect we can explain the reasoning more clearly than
“this needs a step back” 1. Maybe just “we like #276 better because
$REASONS”?

Copy link
Member

Choose a reason for hiding this comment

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

That's what we're working on right now. :-)

Copy link
Contributor

Choose a reason for hiding this comment

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

On Wed, Jan 13, 2016 at 12:11:23PM -0800, Vincent Batts wrote:

That's what we're working on right now. :-)

Excellent :). I don't see the need to land #300 with WIP wording and
follow-up PRs, but as long as the motivation gets documented
somewhere, I'm happy.


*Owner:* vbatts

### Validation Tooling
### Validation Tooling (Target release: v0.3.0)

Provide validation tooling for compliance with OCI spec and runtime environment.

Expand All @@ -78,12 +88,18 @@ Provide a testing framework for compliance with OCI spec and runtime environment

Decide on a robust versioning schema for the spec as it evolves.

*Owner:*
Resolved but release process could evolve. Resolved for v0.2.0, expect to revisit near v1.0.0

*Owner:* vbatts

### Printable/Compiled Spec

Regardless of how the spec is written, ensure that it is easy to read and follow for first time users.

Part of this is resolved. Produces an html & pdf.
Done
Would be nice to publish to the OCI web site as part of our release process.

*Owner:* vbatts

### Base Config Compatibility
Expand All @@ -96,9 +112,11 @@ Systems:
* Windows
* Linux

*Owner:*
*Owner:* robdolinms as lead coordinator

### Full Lifecycle Hooks
Ensure that we have lifecycle hooks in the correct places with full coverage over the container lifecycle.

Will probably go away with Vish's work on splitting create and start, and if we have exec.

*Owner:*