-
Notifications
You must be signed in to change notification settings - Fork 18.6k
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
Make FROM scratch
a special cased 'no-base' spec
#8827
Conversation
This modifies more files than necessary only because I renamed |
I think this may affect a lot of beginning docker users if they forget to add a Will require doc changes as well |
@jlhawn is this necessary? We might re-introduce this requirement with another proposal I'm working on for Dockerfile v2. |
to clarify: I like scratch being "special" but I don't think the implicit FROM is going to work out in the long run. |
@erikh @thaJeztah There was discussion about this in #4242 @shykes, @vieux and a few others seemed to be in agreement that making I'll update this with a change to the tests and documentation. |
Like I said, we're going to be fixating the FROM requirement in Dockerfile v2. It is not going to be healthy for our users to have this changed twice. |
@@ -575,7 +575,7 @@ func (daemon *Daemon) newContainer(name string, config *runconfig.Config, img *i | |||
Args: args, //FIXME: de-duplicate from config | |||
Config: config, | |||
hostConfig: &runconfig.HostConfig{}, | |||
Image: img.ID, // Always use the resolved image id | |||
ImageID: imgID, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what happens here if the imgID is an empty string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing happens at all :)
The container create logic just passes the image id string to the storage graph driver which knows how to handle it when making the container init layer.
It doesn't affect users at all (You can't do docker run ""
for example) but if you do docker ps
you get something like this (I ran docker build -t busybox --rm=false --no-cache .
):
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ce55b20a0180 8a3051d7cf1a "/bin/sh -c '#(nop) 28 hours ago suspicious_pike
8e1877d9055b bbab8f8ff236 "/bin/sh -c '#(nop) 28 hours ago furious_bartik
907893df670c "/bin/sh -c '#(nop) 28 hours ago silly_ptolemy
and docker inspect 907893df670c
shows the container's image as ""
also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. Can you adjust ps to say “scratch” or “” or something similar? That might be nice to clarify what’s going on here.
On Oct 29, 2014, at 10:51 AM, Josh Hawn notifications@github.com wrote:
In daemon/daemon.go:
@@ -575,7 +575,7 @@ func (daemon *Daemon) newContainer(name string, config *runconfig.Config, img *i
Args: args, //FIXME: de-duplicate from config
Config: config,
hostConfig: &runconfig.HostConfig{},
Image: img.ID, // Always use the resolved image id
Nothing happens at all :)ImageID: imgID,
The container container create logic just passes the image id string to the storage graph driver which knows how to handle it when making the container init layer.
It doesn't affect users at all (You can't do docker run "" for example) but if you do docker ps you get something like this (I ran docker build -t busybox --rm=false --no-cache .):
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ce55b20a0180 8a3051d7cf1a "/bin/sh -c '#(nop) 28 hours ago suspicious_pike
8e1877d9055b bbab8f8ff236 "/bin/sh -c '#(nop) 28 hours ago furious_bartik
907893df670c "/bin/sh -c '#(nop) 28 hours ago silly_ptolemy
and docker inspect 907893df670c shows the container's image as "" also.—
Reply to this email directly or view it on GitHub https://github.com/docker/docker/pull/8827/files#r19557572.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's the context of the docker build -t busybox ...
from above. I used Jerome's busybox repo: https://github.com/jpetazzo/docker-busybox
but modified the Dockerfile to remove FROM scratch
:
MAINTAINER Jérôme Petazzoni <jerome@docker.com>
ADD rootfs.tar /
CMD ["/bin/sh"]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. Can you adjust ps to say “scratch” or “” or something similar? That might be nice to clarify what’s going on here.
I thought leaving it empty makes it pretty clear. It also follows what the other fields do when there's nothing to display, for example, thePORTS
columns don't say <no ports>
, it just leaves it empty.
Also, that field typically only shows an image ID or tagged repository name. I don't want to introduce a placeholder name like scratch
since it would cause an issue if the user actually had a legitimate image named scratch
. I'm agreeable to a placeholder like <no image>
if other people are okay with it as long as it's on the client side and isn't something the daemon sets in the api response. I think the API responses for GET /containers/json
and GET /containers/(id)/json
should still return something with {"image": ""}
in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on <no image>
or simply <none>
; it's just a bit clearer that the image column is deliberately empty (maybe the same should be applied for other columns?
If people want to grep
for this, <no image>
is probably more helpful than <none>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thaJeztah @erikh I've added <no image>
to what the client will now output on docker ps
with the latest update.
Once my comments are addressed, LGTM |
I hope this is not a huge blocker for you @jlhawn but I'd prefer to wait a little on this one, as we're rethinking Dockerfiles and versioning of them and this might actually be a nuisance in a scenario where we want to take advantage of the fact that all current Dockerfiles have a FROM statement in the beginning. Will get back to this PR as shortly as I can :) |
30910e6
to
549ddae
Compare
FROM
optional for base image DockerfilesFROM scratch
a special cased 'no-base' spec
With the latest change, we're now back to requiring |
ok. I’ll review this tonight, thanks!
|
85d76cf
to
eb9ddfd
Compare
Integration tests are failing on drone? Update; nvm, see you updated the PR |
one of the integration tests try to tag something as |
Alright then, didn't know if you would notice it before Erik would start reviewing :) |
meh, I'll just work these out locally. don't mind the red |
eb9ddfd
to
965339a
Compare
I think it needs a quick docs pass to ensure "scratch" is explained well, but LGTM from me. |
Will do, but before I start, I'd like a definitive 'yes, we're going with this' from the core maintainers. |
As I mentioned on the issue, I'm very strongly -1 on this because of the |
I honestly don't know about this one, I am uneasy as it might be confusing for |
@jfrazelle @tianon I think this PR was changed after starting; initially it made the Yup, it's confusing 😄 |
oooo ok wow, now caught up |
@jlhawn can you confirm the above is true, and its not removing the |
@tiborvass Let's see what these tests say |
@tiborvass it's back to being merge-able. can you and @erikh, and anyone else you need, please review |
Will do tonight
|
LGTM |
thanks @erikh! what do you think @tiborvass, @tianon ? |
@@ -230,9 +230,9 @@ func TestEventsRedirectStdout(t *testing.T) { | |||
|
|||
func TestEventsImagePull(t *testing.T) { | |||
since := time.Now().Unix() | |||
pullCmd := exec.Command(dockerBinary, "pull", "scratch") | |||
pullCmd := exec.Command(dockerBinary, "pull", "busybox") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're just looking for something tiny, the hello-world
image is even smaller than busybox
. 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
♥ hello-world
would make test execution faster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I missed this one. I meant to switch it to docker_scratch
too. We can't use scratch
anymore because the tagStore will refuse to install it with that name. Do you recommend that I switch this to hello-world
in the other location (https://github.com/docker/docker/pull/8827/files#r22012185) too?
411eaa6
to
e2dd604
Compare
I've rebased again. I also modified some test cases to pull the small |
The new public top-level image |
@tianon It should be safe to remove it now since the tests shouldn't be pulling it any more. |
There has been a lot of discussion (issues 4242 and 5262) about making `FROM scratch` either a special case or making `FROM` optional, implying starting from an empty file system. This patch makes the build command `FROM scratch` special cased from now on and if used does not pull/set the the initial layer of the build to the ancient image ID (511136ea..) but instead marks the build as having no base image. The next command in the dockerfile will create an image with a parent image ID of "". This means every image ever can now use one fewer layer! This also makes the image name `scratch` a reserved name by the TagStore. You will not be able to tag an image with this name from now on. If any users currently have an image tagged as `scratch`, they will still be able to use that image, but will not be able to tag a new image with that name. Goodbye '511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158', it was nice knowing you. Fixes moby#4242 Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
e2dd604
to
8936789
Compare
@tianon I've updated the tests to work with an image it creates called @unclejack once the current test/build passes this should be okay for you to review again. |
🎉 👍 ❤️ |
LGTM |
LGTM |
Make `FROM scratch` a special cased 'no-base' spec
@jlhawn Thank you for your patience and for flying DockAir :) |
Make
FROM scratch
a special cased 'no-base' specThere has been a lot of discussion (issues 4242 and 5262) about making
FROM scratch
either a special case or makingFROM
optional, implyingstarting from an empty file system.
This patch makes the build command
FROM scratch
special cased from now onand if used does not pull/set the the initial layer of the build to the ancient
image ID (511136ea..) but instead marks the build as having no base image. The
next command in the dockerfile will create an image with a parent image ID of "".
This means every image ever can now use one fewer layer!
This also makes the image name
scratch
a reserved name by the TagStore. Youwill not be able to tag an image with this name from now on. If any users
currently have an image tagged as
scratch
, they will still be able to use thatimage, but will not be able to tag a new image with that name.
Goodbye '511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158',
it was nice knowing you.
Fixes #4242