ROADMAP: Remove stale targets (landed PRs, image-spec, ocitools, etc.)
# digest/hashing target Most of this has spun off with [1], and I haven't heard of anyone talking about verifying the on-disk filesystem in a while. My personal take is on-disk verification doesn't add much over serialized verification unless you have a local attacker (or unreliable disk), and you'll need some careful threat modeling if you want to do anything productive about the local attacker case. For some more on-disk verification discussion, see the thread starting with [2]. # distributable-format target This spun off with [1]. # lifecycle target I think this is resolved since7713efc1
(Add lifecycle for containers, 2015-10-22, #231), which was committed on the same day as the ROADMAP entry (4859f6da
, Add initial roadmap, 2015-10-22, #230). # container-action target Addressed by7117ede7
(Expand on the definition of our ops, 2015-10-13, #225), although there has been additional discussion ina7a366b3
(Remove exec from required runtime functionalities, 2016-04-19, #388) and 0430aaf1 (Split create and start, 2016-04-01, #384). # validation and testing targets Validation is partly covered bycdcabdeb
(schema: JSON Schema and validator for `config.json`, 2016-01-19, #313) and subequent JSON Schema work. The remainder of these targets are handled by ocitools [3]. # printable/compiled-spec target The bulk of this was addressed by4ee036fc
(*: printable documents, 2015-12-09, #263). Any remaining polishing of that workflow seems like a GitHub-issue thing and not a ROADMAP thing. And publishing these to opencontainers.org certainly seems like it's outside the scope of this repository (although I think that such publishing is a good idea). [1]: https://github.com/opencontainers/image-spec [2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/xo4SQ92aWJ8/NHpSQ19KCAAJ Subject: OCI Bundle Digests Summary Date: Wed, 14 Oct 2015 17:09:15 +0000 Message-ID: <CAD2oYtN-9yLLhG_STO3F1h58Bn5QovK+u3wOBa=t+7TQi-hP1Q@mail.gmail.com> [3]: https://github.com/opencontainers/ocitools Signed-off-by: W. Trevor King <wking@tremily.us>
This commit is contained in:
parent
be7676409b
commit
23e03f9de3
48
ROADMAP.md
48
ROADMAP.md
|
@ -10,26 +10,6 @@ Listed topics may defer to the [project wiki](https://github.com/opencontainers/
|
|||
|
||||
## 1.0
|
||||
|
||||
### Digest and Hashing
|
||||
|
||||
A bundle is designed to be moved between hosts.
|
||||
Although OCI doesn't define a transport method we should have a cryptographic digest of the on-disk bundle that can be used to verify that a bundle is not corrupted and in an expected configuration.
|
||||
|
||||
*Owner:* philips
|
||||
|
||||
### Define Container Lifecycle
|
||||
|
||||
Containers have a lifecycle and being able to identify and document the lifecycle of a container is very helpful for implementations of the spec.
|
||||
The lifecycle events of a container also help identify areas to implement hooks that are portable across various implementations and platforms.
|
||||
|
||||
*Owner:* mrunalp
|
||||
|
||||
### 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:* duglin
|
||||
|
||||
### Container Definition
|
||||
|
||||
Define what a software container is and its attributes in a cross platform way.
|
||||
|
@ -46,18 +26,6 @@ Proposal: make it an optional feature
|
|||
|
||||
*Owner:* hqhq (was vishh) robdolinms, bcorrie
|
||||
|
||||
### Validation Tooling (Target release: v0.3.0)
|
||||
|
||||
Provide validation tooling for compliance with OCI spec and runtime environment.
|
||||
|
||||
*Owner:* mrunalp
|
||||
|
||||
### Testing Framework
|
||||
|
||||
Provide a testing framework for compliance with OCI spec and runtime environment.
|
||||
|
||||
*Owner:* liangchenye
|
||||
|
||||
### Version Schema
|
||||
|
||||
Decide on a robust versioning schema for the spec as it evolves.
|
||||
|
@ -66,16 +34,6 @@ Resolved but release process could evolve. Resolved for v0.2.0, expect to revisi
|
|||
|
||||
*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
|
||||
|
||||
Ensure that the base configuration format is viable for various platforms.
|
||||
|
@ -95,9 +53,3 @@ Ensure that we have lifecycle hooks in the correct places with full coverage ove
|
|||
Will probably go away with Vish's work on splitting create and start, and if we have exec.
|
||||
|
||||
*Owner:*
|
||||
|
||||
### Distributable Format
|
||||
|
||||
A common format for serializing and distributing bundles.
|
||||
|
||||
*Owner:* vbatts
|
||||
|
|
Loading…
Reference in New Issue