manifest: Require support for runtime-spec configurations

[wking]

We probably need to keep application/vnd.oci.image.config.v1+json untouched, since #145 and other maintainer activity suggest a goal of bit-for-bit compatibility with the current Docker schemas (excepting media types). However, requiring Docker support doesn't mean we can't also require support for configuration formats that are easier for image authors to use.

Of course, with the (greatly) increased flexibility comes a lot more risk. Image consumers in general, and runtime-spec-based-image consumers in particular, should use a sanitization tool like the one I've floated in opencontainers/runtime-tools#219.

The runtime-spec config also lacks support for diffIDs, but local image tooling is still welcome to record the digests of uncompressed layers and use that for local optimizations. You have to fetch the compressed layer at least once to perform the uncompression, but you'd have to do that to verify the old diffID anyway.

This PR requires opencontainers/runtime-spec#611 for typing the runtime-spec config.

[wking]

The current spec is pretty vague about how application/vnd.oci.image.config.v1+json should be unpacked. I've filed #454 to make that more clear, and then rebased this PR on top of #454. So #454 should be reviewed first (it is independent of whether we require support for application/vnd.oci.runtime.config.v1+json), and this PR should be reviewed if/when both #454 and opencontainers/runtime-spec#611 have landed.

[stevvooe]

Rejected

This places unnecessary portability requirements on the runtime-spec and unnecessary cross-platform requirements on the image-spec. Doing this will result in an over-coupled system, that is inflexible and complex to upgrade.

Docker spent several versions decoupling these and it would be unfortunate if OCI went in the opposite direction.

I would be much in favor of making a version of the config that is driven based on the actual requirements of an image, rather than a misplaced notion of DRY or NIH.

[wking]

On Mon, Nov 21, 2016 at 12:21:38PM -0800, Stephen Day wrote:

This places unnecessary portability requirements on the runtime-spec
and unnecessary cross-platform requirements on the image-spec. Doing
this will result in an over-coupled system, that is inflexible and
complex to upgrade.

Docker spent several versions decoupling these and it would be
unfortunate if OCI went in the opposite direction.

This PR is asking for:

configDigest := manifest.Config.digest
configReader, err := casEngine.Get(configDigest)
configWriter, err := os.OpenFile("config.json", os.O_WRONLY | os.O_CREAT, 0666)
defer configWriter.close()
_, err := ioutil.Copy(configWriter, configReader)

With the current spec, most unpackers would presumably error out with
something like:

“I have no idea how to create a runtime config from an
application/vnd.oci.runtime.config.v1+json blob.”

The only implementation I can think of that's more decoupled is “the
image-spec has no provision for sharing runtime configurations; handle
that out of band”.

[stevvooe]

@wking There are a lot of implications to doing this. Per @philips during the weekly meeting, we should have some implementation directive that explains why this is such a problematic concept.

[philips]

I 100% agree, we shouldn't do this. The config.json is explicitly not portable between hosts and we should add language to the runtime-spec to say that these configs are designed not to be transported or largely even moved between hosts.

[philips]

closing xref #479

[wking]

On Wed, Nov 30, 2016 at 02:47:49PM -0800, Brandon Philips wrote: The config.json is explicitly not portable between hosts…

Portable is a fuzzy line which depends on the distribution context. If I'm only distributing within my cluster a large fraction of the runtime config will be portable. But if I'm distributing to generic hosts via a public registry a much smaller fraction will be portable. This fuzziness is why we rolled back the portable/specific split in opencontainers/runtime-spec#284. I think the same fuzziness will be a problem with any translation from an image config to a runtime config, and think that this PR is a sane way to empower users to make their own portability calls (via post-unpack sanitization). However, a well-defined mapping between image configs and runtime configs (following the initial work in #454 and #479) will cover whatever portions of the runtime config that the image-spec maintainers feel are sufficiently portable to distribute. And folks can always use ~~annotations~~ Labels to distribute everything else. I just think that's more hoop-jumping than it's worth.