manifest: Require unpackers to create a config.json from the referenced config

[wking]

The image-tools framework has attempted this since #114, but we didn't specify whether the translation was required or what the output of the translation should be. That means downstream consumers of an unpacked image couldn't be sure if they'd find a config.json or (if they found one) which runtime-spec versions it would be compatible with. With this commit, the config output becomes specified, so consumers can post-process their config.json and/or invoke a runtime-spec 1.0.0-rc2-compatible runtime on it without worrying about the presence or version of the unpacked config.json.

I've picked 1.0.0-rc2 as the most recent runtime-spec commit. As the runtime-spec moves forward with more RCs, I expect we'll want to bump this to keep up. Once runtime-spec hits 1.0, we can probably freeze the target, since post 1.0 releases in runtime-spec's 1.x line are unlikely to make translation from the config format easier, and any 1.x-compatible runtime will be able to handle 1.0 configs.

[jonboulle]

I don't think this is right; some implementations of image-spec might not care about runtime-spec at all. What about something like "Implementations that are generating a runtime-spec compliant config.json SHOULD use the parameters from this configuration as a basis" or similar?

[wking]

...some implementations of image-spec might not care about runtime-spec at all.

So they'd unpack application/vnd.oci.image.config.v1+json to whatever they like? I guess I'd be ok with that if we provided a standard unpacker API so you could require the runtime-caller output. Otherwise we have standard formats on both sides but no standard way to get between them. And it seems like portable images would be difficult if the mapping was implementation-defined ("oh, you unpacked that config with umoci? I was expecting the image-tools translation").

[jonboulle]

Yeah, part of the problem here is terminology (c.f. #467). But if we accepted your wording, a strict reading of the spec would preclude implementations that just e.g. manipulate images without caring about generating runtime versions.

[wking]

But if we accepted your wording, a strict reading of the spec would preclude implementations that just e.g. manipulate images...

As it stands, this PR only constrains implementations that are "unpacking" manifests. So I don't see a problem, but I'm fine waiting on #467 and a formal definition for unpacking.

[stevvooe]

Rejected.

Why would we so tightly couple unpacking and conversion? In practice, there are two components to an image, a config and the root filesystem. From an image spec perspective, its only role is to provide a root filsystem and an unprocessed configuration.

If we force the unpacker to understand the runtime spec, we prevent compliant implementations from leveraging intermediate formats. We also prevent image-spec complaint unpackers from working with non-oci runtimes. There are many details reqiured in generating a runtime config that we don't want the image processing components to have to understand.

[wking]

On Wed, Dec 07, 2016 at 11:36:47AM -0800, Stephen Day wrote: From an image spec perspective, its only role is to provide a root filsystem and an _unprocessed_ configuration.

Offloading the image↔runtime config translation to an external spec/tooling is fine (and I actually like that approach better [1]). But I'm not aware of any out-of-image-spec plans to specify the translation, the current reference implementation for translation is in image-tools [2], and there are plans to land a backing spec for that translation in image-spec (#479). I don't really care which repos the spec / tooling for the translation live in, but I think we'll have interop issues if we don't specify the translation somewhere.

There are many details reqiured in generating a runtime config that we don't want the image processing components to have to understand.

Agreed (and what I was trying to address in #451). But without #451 or some other way to ask for “just copy this opaque config blob into the target directory” [3], I don't think there's a way to avoid this. *Somebody* in the chain is going to have to understand how to translate configs. Callers need a well-defined way to get a particular version of runtime-spec config in the bundle before they call the runtime. There could be well-defined ways to get to *other* output formats too (the runtime-spec translation doesn't have to be exclusive), but you can't skip the runtime-spec translation entirely. [1]: #87 (comment) [2]: https://github.com/opencontainers/image-tools/blob/421458f7e467ac86175408693a07da6d29817bf7/image/config.go#L68-L141 [3]: #451 (comment)

[vbatts]

closing in favor of #492