container runconfig in Image Configuration is linux centric

[coolljt0725]

The container runconfig(https://github.com/opencontainers/image-spec/blob/master/config.md#container-runconfig-field-descriptions) in Image Configuration is very linux centric.

I think this field should be platform specific, I think we should have a clarification about this.

[wking]

On Mon, Sep 19, 2016 at 04:55:53AM -0700, Lei Jitang wrote:

The container runconfig in Image Configuration is very linux
centric.

I think this field should be platform specific, I think we should
have a clarification about this.

See 1 and similar for why I think image-spec should get out of the
runtime-configuration re-specification business. As long as it stays
in that business, it will have to work to keep up with
opencontainers/runtime-spec#565 and similar, which seems like
duplicated effort to me.

[coolljt0725]

@wking I think image-spec provides some basic runtime-configuration make sense. With some basic runtime configuration, user can run a container with no additional arguments. For some images, a user may doesn't know what arguments should be set on container creation. a image provider distribute a image and the user just run it with no additional arguments.

[wking]

On Mon, Sep 19, 2016 at 07:19:03PM -0700, Lei Jitang wrote:

With some basic runtime configuration, user can run a container with
no additional arguments.

If distribute the whole bundle with layers (instead of just the
rootfs), then you can distribute an image-spec config.json which
you've made as complete as you wish. Image consumers can unpack your
image, adjust the config.json as they see fit (e.g. sanitizing hooks,
mounts, etc.) and away they go. If there is a consensus about what
should be sanitized, you could write the sanitizer in image-tools, and
have an orchestrator (also in image-tools?) which would 1:

1. Call oci-unpack to unpack a generic directory
2. Call oci-sanitize to remove suspicious entries from the config.json
3. Call oci-network to convert a config file's networking description
   (e.g. an exposed ports listing) to libnetwork hooks (or some such).
4. Call runtime-spec tooling (e.g. runC) to launch the adapted config.

So you still get “just run it” support. And the number of things you
can run goes up tremendously (with sanitization to protect you from
having it go too far, for your particular definition of “too far”).
And the amount of work that the image-spec maintainers have to put in
goes down to zero. oci-sanitize and oci-network spring into existence
(in image-tools?) to handle security and functionality that is not
covered by runtime-spec, but nobody has to waste time porting safe
changes like opencontainers/runtime-spec#565 over to a
similar-but-different runtime-config spec (which is what
v1.Image.Config is now).

[vbatts]

@coolljt0725 Would you open the PRs for the changes you'd like to see?