# 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 7713efc1 (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 by 7117ede7 (Expand on the definition of our ops,
2015-10-13, #225), although there has been additional discussion in
a7a366b3 (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 by cdcabdeb (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 by 4ee036fc (*: 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>
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
We discussed this in the face to face meeting and agreed
that it makes sense to keep the rootfs as is for flexibility.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
W. Trevor King
Vincent Batts
Mrunal Patel
Mrunal Patel
Doug Davis
Swapnil Kulkarni (coolsvap)
Lai Jiangshan
Liang Chenye
Michael Crosby