jasder
/
runc
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge pull request #300 from duglin/patch-1 

Update ROADMAP.md
This commit is contained in:
Vincent Batts 2016-01-13 14:30:03 -05:00
parent 837f67d46b 0fe5798279
commit 588d54b350
1 changed files with 27 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
ROADMAP.md
View File

@ -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
@ -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
*Owner:* vbatts
### Validation Tooling
### Validation Tooling (Target release: v0.3.0)
Provide validation tooling for compliance with OCI spec and runtime environment.
@ -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
@ -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:*