Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

container runconfig in Image Configuration is linux centric #329

Closed
coolljt0725 opened this issue Sep 19, 2016 · 4 comments
Closed

container runconfig in Image Configuration is linux centric #329

coolljt0725 opened this issue Sep 19, 2016 · 4 comments

Comments

@coolljt0725
Copy link
Member

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
Copy link
Contributor

wking commented Sep 19, 2016

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
Copy link
Member Author

@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
Copy link
Contributor

wking commented Sep 20, 2016

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
Copy link
Member

vbatts commented Oct 6, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants