Skip to content

Commit

Permalink
ROADMAP: Remove stale targets (landed PRs, image-spec, ocitools, etc.)
Browse files Browse the repository at this point in the history
# 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 since 7713efc (Add lifecycle for containers,
2015-10-22, opencontainers#231), which was committed on the same day as the ROADMAP
entry (4859f6d, Add initial roadmap, 2015-10-22, opencontainers#230).

# container-action target

Addressed by 7117ede (Expand on the definition of our ops,
2015-10-13, opencontainers#225), although there has been additional discussion in
a7a366b (Remove exec from required runtime functionalities,
2016-04-19, opencontainers#388) and 0430aaf1 (Split create and start, 2016-04-01,
opencontainers#384).

# validation and testing targets

Validation is partly covered by cdcabde (schema: JSON Schema and
validator for `config.json`, 2016-01-19, opencontainers#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 by 4ee036f (*: printable documents,
2015-12-09, opencontainers#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>
  • Loading branch information
wking committed May 15, 2016
1 parent be76764 commit 23e03f9
Showing 1 changed file with 0 additions and 48 deletions.
48 changes: 0 additions & 48 deletions ROADMAP.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand All @@ -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.
Expand All @@ -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.
Expand All @@ -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

0 comments on commit 23e03f9

Please sign in to comment.