What about the other configuration options? Is ENV currently the only one that you think makes sense for a base image?

I have a another patch for the COMMENT field. And we would like to add a META/Vendor field, to allow vendors to add json information to images. Have not thought of any thing else. But I would guess anything that can be added to the json file about a layer should be available to the Base IMage.

Docs LGTM Ping @fredlf @SvenDowideit @ostezer

Docs LGTM.

same info needs to be added to the cli.md :)

Updated cli.md

docs LGTM

Docs LGTM

@crosbymichael Any other changes needed?

ping @shykes this is a UI change to make it possible for image authors to set environment variables in the base image when they import the tarballs into docker.

Please review.

@crosbymichael @shykes Can this pull request get some love. Does not seem too controversial.

I'm running this but it's not working.

root@7c7f4212a8cd:/test# docker import -e="name=michael" - < busybox.tar

7ba3aaf318d1f88b61ae2e869ba95f2bab9c24653be7015cd57a92287aad081c

root@7c7f4212a8cd:/test# docker run 7ba3aaf318d1f88b61ae2e869ba95f2bab9c24653be7015cd57a92287aad081c env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=2c755fd6c190
HOME=/root

I seemed to have lost a bit of the patch.

For some reason I can not test this, although the json file looks like the content is there.

How are you creating the busybox.tar?

docker save -o /tmp/busybox.tar busybox:latest
docker import -e "name=mike" - < /tmp/busybox.tar
03175c8214ba26d5c7f06f29aef33702609bbfa4dc93ec933b868aa6ffcc6982
docker run -ti 03175c8214ba /bin/sh
exec: "/bin/sh": stat /bin/sh: no such file or directory2014/08/13 16:18:08 Error response from daemon: Cannot start container 153c0ad6af71c5e28c7e0a08bc3591e0906a498e6ec579073e5d6b8907c13e2a: exec: "/bin/sh": stat /bin/sh: no such file or directory

You have to use docker export to get a clean tarball of the rootfs.

Thanks. Then why do we have docker save?

docker import -e name=mike - < /tmp/dan
b66679d2d9cc41c32bdd990dbfe76bf117a686cb9de8ae3fcf175b359dc1eef8

docker run --rm -ti b66679d2d9cc /bin/sh

printenv

HOSTNAME=e55b555d0628
TERM=xterm
name=mike
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
SHLVL=1
HOME=/root
_=/usr/bin/printenv

Seems to work.

"docker save" correlates with "docker load" and saves all the layers as
layers so you get a true image copy instead of a squashed rootfs like you
get from export.

Well docker import should probably blow up if you use the output of docker save. Rather then giving you an image that can not be run.

@crosbymichael Can you recheck this merge request?

I'm getting a panic running the integration tests

--- FAIL: TestExportContainerAndImportImage (0.74 seconds)
        utils.go:125: failed to import image: panic: runtime error: invalid memory address or nil pointer dereference
                [signal 0xb code=0x1 addr=0x0 pc=0x53d36d]

                goroutine 16 [running]:
                runtime.panic(0xb48340, 0x1174573)
                        /usr/local/go/src/pkg/runtime/panic.c:279 +0xf5
                github.com/docker/docker/opts.(*ListOpts).String(0xc208037660, 0x0, 0x0)
                        /go/src/github.com/docker/docker/opts/opts.go:55 +0x11d
                github.com/docker/docker/pkg/mflag.(*FlagSet).Var(0xc208004300, 0x7fd40b67c188, 0xc208037660, 0xc20803
76e0, 0x1, 0x1, 0xc98250, 0x36)
                        /go/src/github.com/docker/docker/pkg/mflag/flag.go:724 +0x43

Is there an easy way to run individual tests?

You can set TESTFLAGS='-run TestName' when you run make test or however you are running the integration tests

This seems to be the error.
var (
flEnv = opts.NewListOpts(opts.ValidateEnv)

•           flEnvFile opts.ListOpts
  

•           flEnvFile = opts.NewListOpts(nil)
  )
  

But I still can't get the test suite to run here.

This patch has been updated and seems to work for me.

Back from Vacation, updating Pull Requests and seeing if there is anything I can do to move these along.

Another week no action.

@tianon I don't think this takes away from Dockerfile based building. You have to start from something and if you can get a complete base image into docker with all the configuration data then it's a big win. Also I hate it when I pull down a base image and it has multiple layers just for metadata :) I know that is how you have started building things so that you can only use dockerfiles but to keep a super small image I perfer the one layer with everything.

LGTM

@tianon @shykes Can this pull request get a little love?

LGTM

Wouldn't having a generic configuration flag be better, rather than adding specific flags? I think having the possibility of setting configuration options for all commands which produce images would be better.

A generic configuration flag could be used to provide all the configuration of the image in one layer. This configuration flag could also be used for commit.

Please take this alternative option into consideration, we'll have to carry this flag and deprecate it if we decide to migrate to the generic configuration flag.

@unclejack 👍

This was the start of the last generic flag to mirror all the dockerfile options

#5105

What about having an option to make import create a container instead of an image (similarly to export exporting a container fs not an image).

That way one would be able to add any metadata that docker end up exposing on commit.

This patch will be replaced when #8332 gets merged with docker import support.

@rhatdan Can we close this PR?

@rhatdan whats the status of this since #8332 was merged

EDIT: it was closed actually, #8765 is waiting on approval
disregard question

Right as soon as we have docker import --change ENV:name=value
This can be closed.

ok cool! thanks :)

Willing to work with the docker import --change patch.
#9123