Layer id is <missing>

[kiwenlau]

Thanks for this great project.

Since docker 1.1.0, docker image and layer are different things. Each image has an ID while layer only has hash checksum. Therefore, I find that layer id is when use dockviz

dockviz images -t
└─<missing> Virtual Size: 6.1 MB
  └─<missing> Virtual Size: 6.1 MB
    └─sha256:3ee5f Virtual Size: 6.1 MB Tags: nate/dockviz:latest

dockviz images -d | dot -Tpng -o images.png

It looks better if we can replace missing with the hash checksum of each layer....

[kkirsche]

I'm also experiencing this behavior

[kj54321]

Same issue here, any plans to update and support new docker version?

├─<missing> Virtual Size: 6.1 MB
│ └─<missing> Virtual Size: 6.1 MB
│   └─sha256:3ee5f Virtual Size: 6.1 MB Tags: nate/dockviz:latest
├─<missing> Virtual Size: 124.5 MB
│ └─<missing> Virtual Size: 124.9 MB
│   └─<missing> Virtual Size: 124.9 MB
│     └─<missing> Virtual Size: 124.9 MB
│       └─sha256:cf623 Virtual Size: 124.9 MB Tags: ubuntu:latest
└─<missing> Virtual Size: 1.8 KB
  └─sha256:c54a2 Virtual Size: 1.8 KB Tags: hello-world:latest

[justone]

Thank you for your feedback. You are right, as of Docker 1.10.0 images and layers are decoupled. This means that for some layers there is no image data. That's where the <missing> comes from. If you look at the output from docker history nate/dockviz, you will see the same <missing> tag show up:

$ docker history nate/dockviz
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
143d6907480f        4 weeks ago         /bin/sh -c #(nop) ENTRYPOINT ["/dockviz"]       0 B                 
<missing>           4 weeks ago         /bin/sh -c #(nop) ENV IN_DOCKER=true            0 B                 
<missing>           4 weeks ago         /bin/sh -c #(nop) COPY file:a38fa63ac93b432e1   6.107 MB

Here is the relevant documentation on docs.docker.com. Look for "missing".

Dockviz could show a generated checksum for the missing layers (and in fact there is one generated internally so that parentage can be determined), but doing this would confuse anyone who tried to use that checksum with any other docker command, such as docker inspect ..., docker run ..., or as the FROM instruction in a Dockerfile.

So, for that reason, I keep the interface consistent with what Docker itself provides. If Docker ever starts generating checksums instead of showing <missing>, then Dockviz will show those checksums.

I agree that it would look better if there were checksums in each line, but keeping the display consistent with Docker is more important.

Thank you.

EDIT: fixed Docker version where issue started

[kkirsche]

While I understand the logic, I think that from a teaching perspective, having checksums can still be valuable. In my opinion, I'd prefer this to be a flag which is optional, though I agree it shouldn't necessarily be default behavior if this is consistent with Docker.

[justone]

What value do the checksums provide for teaching? Any checksum generated by dockviz is only valid in finding parentage, and once that is discovered, the lineage is depicted by the hierarchy (in --tree) or the arrows (in --dot). It's the lineage that's important to see, not any one checksum.

Also, showing a dockviz-generated checksum that isn't there when someone runs it on their own (because they forgot the flag) would be confusing.

[kkirsche]

While it may not be of value to you once you know Docker and understand how it works, when teaching Docker and how images work, in terms of layering. <missing> really doesn't do anything to show or help understand the actual differences which exist between layers and in many cases comes across as if images are installed incorrectly or are broken.

I agree that for individuals comfortable with images and the concepts of layering, this wouldn't be helpful, but I feel it's a very helpful example for individuals who are still learning the core concepts of how Docker images are built and how they exist structurally, which hierarchy alone really doesn't re-enforce when it's made up of all <missing> layer checksums.

[coreyfarrell]

Seems like 'missing' is a bad term, when I first saw it I was afraid I was experiencing corruption. Maybe better if it said 'anonymous' or something similar. That way it would be clear the image is not missing, just that it doesn't have an identifier.

[justone]

You make a good point. How about having the content of the layer id be "ID: ", indicating that the ID is missing but not the layer itself? I think I would even be open to "ID: [not available]" or something like that.

The big reason why I don't want to put the internally generated checksums out there is that there is the possibility that people will take them and pass them as arguments to regular Docker commands such as docker tag ... or docker run ..., causing more confusion.

[coreyfarrell]

The 'ID:' prefix seems reasonable especially since you have Size: and Tag: already. What about 'ID: [none]'? Not available still sounds a bit like 'we failed to find/retrieve the ID'. Agreed on not providing something that looks like an layer id but isn't. Also generating a checksum sounds like it would require a lot of IO (like reading entire images off disk).

[fatherlinux]

+1 on "ID: none" That instills confidence that there is NOT an ID. The "missing" scared me too. I thought there was some kind of corruption, or a new bug with dockviz - glad I found this thread :-)

BTW, @justone thanks for writing dockviz, when docker removed the --tree option I was heartbroken. I do a lot of labs and teaching at Red Hat, and without this tool it would be very difficult to show people how image layers work...

[joernhees]

being mostly on the user end of docker, i've wondered about the <missing> for a while now and only in this issue learned about the reason for it. I think what would've made it a lot clearer to me would've been something like:

└─img: none, layer: beefdeadbeef Virtual Size: 123.0 MB
 └─img: b66ce481fbb1 Virtual Size: 398.3 MB Tags: joernhees/virtuoso:latest

or just

└─layer: beefdeadbeef Virtual Size: 123.0 MB
 └─img: b66ce481fbb1 Virtual Size: 398.3 MB Tags: joernhees/virtuoso:latest

both ways make the tree look a lot less weird and make it obvious that one is the image id and one the layer id. even without understanding it, i'd be able to quickly learn that layers can't be put in docker run <layer> by simple experimentation

[mrwacky42]

@fatherlinux - Fun fact, @justone is the one who wrote the upstream patch to add the --tree option. He wrote dockviz after they removed it.
🎆

[justone]

I just added a --show-created-by for the dockviz images command. It shows the command used to create that layer, which should serve well for showing hierarchy and parentage.

[nobrowser]

I am getting the thing on nodes that are definitely images. Something is wrong here