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

Deprecate 'docker images --tree' and 'docker images --viz' #5001

Merged
merged 1 commit into from Apr 4, 2014

Conversation

Projects
None yet
@shykes
Collaborator

shykes commented Apr 3, 2014

As discussed on #docker-dev, these flags can easily be implemented as external tools. We want to keep the Docker core as small as possible. Let's start cutting down the "nice-to-have" features.

  • The commands are no longer listed or documented.
  • The commands still work but print a deprecation warning.
  • The commands should be removed in a future version.
Solomon Hykes
Deprecate 'docker images --tree' and 'docker images --viz'
* The commands are no longer listed or documented.
* The commands still work but print a deprecation warning.
* The commands should be removed in a future version.

Docker-DCO-1.1-Signed-off-by: Solomon Hykes <solomon@docker.com> (github: shykes)
@crosbymichael

This comment has been minimized.

Member

crosbymichael commented Apr 3, 2014

@shykes what about the tests around these features and moving forward with your other PR? Are they still going to cause issues for you?

@crosbymichael

This comment has been minimized.

Member

crosbymichael commented Apr 3, 2014

LGTM

1 similar comment
@vieux

This comment has been minimized.

Collaborator

vieux commented Apr 4, 2014

LGTM

vieux added a commit that referenced this pull request Apr 4, 2014

Merge pull request #5001 from shykes/deprecate-images-viz-tree
Deprecate 'docker images --tree' and 'docker images --viz'

@vieux vieux merged commit 9f68b93 into moby:master Apr 4, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details
@blalor

This comment has been minimized.

blalor commented Apr 12, 2014

Sad to see --tree go. Can a sample implementation be provided in contrib?

@abierbaum

This comment has been minimized.

abierbaum commented Apr 17, 2014

Agreed. Very sad to see this go. --tree made "docker images" much more useful.

@justone

This comment has been minimized.

Contributor

justone commented Apr 18, 2014

Bummer. As the author of those two features, I'm sad to see them removed. I used --tree daily to get an overview of my image hierarchy.

That being said, I definitely respect the docker team's decision to remove them from core. I'll try to work on a contrib PR to re-introduce them.

@shykes, @crosbymichael, @vieux I have a couple of questions about how best to approach this:

  1. Is there a go client lib I can use to get the images json information or should I go to the API directly?
  2. Is there a plugin mechanism that I can hook into to add a new subcommand to docker so that this fits in naturally with the rest of the system?

Thanks for any help you can give.

@crosbymichael

This comment has been minimized.

Member

crosbymichael commented Apr 18, 2014

What do you all thing about having the cli dump raw json if a debug flag is passed? then the contrib apps can just have the request json piped to them easily?

@crosbymichael

This comment has been minimized.

Member

crosbymichael commented Apr 18, 2014

I'm thinking that the json output will also help us in the integration-cli tests when we want to have a little more control with parsing the results.

@justone

This comment has been minimized.

Contributor

justone commented Apr 18, 2014

That would work for me. Would the debug option be added to other commands too?

Thanks.

@crosbymichael

This comment has been minimized.

Member

crosbymichael commented Apr 18, 2014

I think the raw output would be enabled for all commands

@justone

This comment has been minimized.

Contributor

justone commented Apr 18, 2014

Cool. How can I help? I can try to put together a PR for the debug flags if that would be useful.

@vieux

This comment has been minimized.

Collaborator

vieux commented Apr 18, 2014

I like the idea

@justone

This comment has been minimized.

Contributor

justone commented Apr 22, 2014

I've started my implementation here: https://github.com/justone/dockviz

Only the graphviz one works, but I'll get to the tree version this week sometime.

@vieux

This comment has been minimized.

Collaborator

vieux commented Apr 22, 2014

Great

On Mon, Apr 21, 2014 at 9:17 PM, Nate Jones notifications@github.comwrote:

I've started my implementation here: https://github.com/justone/dockviz

Only the graphviz one works, but I'll get to the tree version this week
sometime.


Reply to this email directly or view it on GitHubhttps://github.com//pull/5001#issuecomment-41002459
.

Victor VIEUX
http://vvieux.com

@vbatts

This comment has been minimized.

Contributor

vbatts commented Jun 17, 2014

I feel like, for this, some of the client side api of docker's code could be opened up a little. Like the call ( https://github.com/dotcloud/docker/blob/master/api/client/utils.go#L42 ), so that other tooling could interact just as the docker client does. Then we could easily have drop in third party tools in a /usr/libexec/docker directory to be called like docker tool images-viz.

I prototype of this https://github.com/vbatts/docker/compare/vbatts-docker_tool and https://gist.github.com/vbatts/60ffdd3df308d1c13967

@magnayn

This comment has been minimized.

magnayn commented Jul 19, 2014

What a dumb move.

@jerng

This comment has been minimized.

jerng commented Jul 28, 2014

First of all, the 'docker image' --tree (and --viz) flag-behaviours are useful (saves time, computation) to anyone who has to manage docker images. I'd like to see evidence from CRM / product management that refutes this claim.

Second, the question then arises about what Docker is supposed to be. A library, or an app? More back-end focus, or more focused on being a front-end? So far, in the grand continuum of cgroup technologies currently available to the average techie, it seems that Docker is more an app, positioned with a higher degree of "naive usability."

If I understood correctly, Docker is a front-end for libcontainer - libcontainer, LMCTFY, and LXC all being front-ends for cgroups. Docker is already twice removed from cgroups... so why take a step backwards and reduce usability for naive users (like me)?

I don't have much say in this, but I'd vote to keep --tree (and --viz if it can be prettified a bit).

@lukebennett

This comment has been minimized.

lukebennett commented Jul 29, 2014

I concur with @jerng - Docker is supposed to be all about reducing friction, and removing visibility of the image hierarchy via --tree is a case of introducing friction as far as I'm concerned.

@romaninsh

This comment has been minimized.

romaninsh commented Aug 7, 2014

I'd suggest that --tree should stay alone for the benefit of new users and ease of use.

@crccheck crccheck referenced this pull request Sep 2, 2014

Open

make a DAG for fun #5

@jhalfmoon

This comment has been minimized.

jhalfmoon commented Nov 8, 2014

I too agree with @jerng and @lukebennett . A flexible, friendly user interface, should not have to interfere with core performance. On the contrary. If --tree, and commands like it, are to be removed from core. then usability will suffer because extra tooling will have to be installed to compensate for functionality lost, making the overall complexity larger, not smaller. Unless ofcourse the extra tooling is supplied along with the core.

@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Nov 8, 2014

@vbatts just saw your (now quite ancient) example for plug-able commands; I think they're quite interesting, have you ever created a proposal out of that, or a PR?

Besides offering extensions to the standard docker command set, they could also be a nice mechanism to preview upcoming docker features during proposal stage, so that people were able to "play around" with a new feature more easily, or would that be very difficult in most cases?

@vbatts

This comment has been minimized.

Contributor

vbatts commented Nov 8, 2014

@thaJeztah i am still very fond of the idea for docker tool <cmd> interface, where the <cmd> is an an executable that lives somewhere like /usr/libexec/docker/cmds/...
It seems like a sensible way to keep the user experience consistent, while allowing drop-in tools for tree visualization, etc.

@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Nov 8, 2014

@vbatts given the current interest in a "plug in" structure for docker, and related proposals, perhaps you should make it into an official proposal / PR?

@vbatts

This comment has been minimized.

Contributor

vbatts commented Nov 8, 2014

Ideally plugins will use libchan, which is a better path than just shelling
out with environment variables. cpuguy83 is working on a plugin POC
currently. I'll look for its progress.

On Sat, Nov 8, 2014 at 6:10 PM, Sebastiaan van Stijn <
notifications@github.com> wrote:

@vbatts https://github.com/vbatts given the current interest in a "plug
in" structure for docker, and related proposals, perhaps you should make it
into an official proposal / PR?


Reply to this email directly or view it on GitHub
#5001 (comment).

@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Nov 9, 2014

Ok, fair. Just saw this as a nice way to bring back some things to docker :)

@RoelVdP

This comment has been minimized.

RoelVdP commented Jan 6, 2015

Would you please consider leaving --tree as-is for the docker command line (it still works as of latest 1.4.1) and instead remove the deprecated warning for --tee and -t. Many people (https://groups.google.com/forum/#!topic/docker-user/KJJkFU6eyGU) including myself clearly would like to keep it. Why make a lot of people in the community unhappy?

@askb

This comment has been minimized.

Contributor

askb commented Oct 26, 2015

+1 to bring back the feature. When dealing with a large number of layers per image and large nums of images per host, using a "--tree" option was a great way we can view the layers associated image. Also companies have policies which don't easily approve using third party plugins / containers for security reasons. Though using dockviz does the trick, its best to bring the original feature back.

@magnayn

This comment has been minimized.

magnayn commented Oct 26, 2015

+1 on what @mikehaertl said.

I don't understand the benefit of having removed such a useful option. It's a bit like if git removed all the user facing porcelain, and forced you to interact directly on the plumbing.

@ytwu

This comment has been minimized.

ytwu commented Nov 4, 2015

+1 to bring back this feature! we need it!!! It's really inconvenient without it.

@jrjr89

This comment has been minimized.

jrjr89 commented Dec 4, 2015

+1 bring it back

@FuzzySockets

This comment has been minimized.

FuzzySockets commented Dec 5, 2015

So it's unanimous. +1 to add it back into the core.

@LordGaav

This comment has been minimized.

LordGaav commented Dec 14, 2015

I would also like this feature returned, or a proper alternative using the core docker tools. As layering images is a core feature of docker, a visualization of these layers should be visible in the core tools.

@shaded-enmity

This comment has been minimized.

shaded-enmity commented Dec 21, 2015

https://github.com/shaded-enmity/docker-doug

doug-cli dependencies IMAGE_NAME

To list images depending on IMAGE_NAME

@adityamenon

This comment has been minimized.

adityamenon commented Dec 28, 2015

I'm less happy knowing that this existed (and seeing screenshots) and not having it now, than I would have been if it was never there at all :)

An error message giving step by step instructions on how to replicate that functionality would at least be a good redressal.

@TomasTomecek

This comment has been minimized.

Contributor

TomasTomecek commented Jan 4, 2016

I have recently released a new version of sen (terminal user interface for docker engine) which contains interactive docker images --tree-like buffer:

https://github.com/TomasTomecek/sen/blob/master/docs/features.md#image-tree

@codeaholics

This comment has been minimized.

Contributor

codeaholics commented Jan 4, 2016

That looks like an awesome project! Thank you for sharing.

@ytwu

This comment has been minimized.

ytwu commented Jan 16, 2016

@TomasTomecek very cool!

@meffect

This comment has been minimized.

meffect commented Jun 3, 2016

user@comp MINGW64 ~ $ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock nate/dockviz images -t Error reading JSON: %!(EXTRA *json.SyntaxError=unexpected end of JSON input)

anyone get this? windows 8.1

@justone

This comment has been minimized.

Contributor

justone commented Jun 3, 2016

Hey @meffect, just need to add -it to your docker run command. This is required as of docker 1.11 (or maybe even 1.10).

And, for anyone that has issues with dockviz, please file an issue over there. Thanks.

@meffect

This comment has been minimized.

meffect commented Jun 3, 2016

thanks it works

docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock nate/dockviz images -t

@pnkjtr

This comment has been minimized.

pnkjtr commented Jun 13, 2016

when i run the above command , i see following o/p.. not sure, what means here. i am expecting proper ID here. any idea, how to correct it ?

pankaj@ubuntu14-04:~$ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock nate/dockviz images -t
─ Virtual Size: 967.0 B
│ └─sha256:94df4 Virtual Size: 967.0 B Tags: hello-world:latest
├─ Virtual Size: 122.0 MB
│ └─ Virtual Size: 122.0 MB
│ └─ Virtual Size: 122.0 MB
│ └─ Virtual Size: 122.0 MB
│ └─sha256:2fa92 Virtual Size: 122.0 MB Tags: ubuntu:latest

@pnkjtr

This comment has been minimized.

pnkjtr commented Jun 13, 2016

re-submitting the exact o./p again.

I am getting in output of 'dockviz images -t' command.

pankaj@ubuntu14-04:~$ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock nate/dockviz images -t
├─<missing> Virtual Size: 967.0 B
│ └─sha256:94df4 Virtual Size: 967.0 B Tags: hello-world:latest
├─<missing> Virtual Size: 122.0 MB
│ └─<missing> Virtual Size: 122.0 MB
│   └─<missing> Virtual Size: 122.0 MB
│     └─<missing> Virtual Size: 122.0 MB
│       └─sha256:2fa92 Virtual Size: 122.0 MB Tags: ubuntu:latest
├─<missing> Virtual Size: 6.1 MB
│ └─<missing> Virtual Size: 6.1 MB
│   └─sha256:3ee5f Virtual Size: 6.1 MB Tags: nate/dockviz:latest
@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Jun 13, 2016

@pnkjtr I edited your last comment to put the output in a code-block (otherwise the <missing> is hidden in HTML)

@pnkjtr

This comment has been minimized.

pnkjtr commented Jun 13, 2016

resubmitting the o/p, since my earlier post made 'missing' hidden when coverted by HTML.

here you can see, i am getting missing tag in each line of 'dockviz images -t' o/p.

is there any thing i am missing ?

pankaj@ubuntu14-04:~$ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock nate/dockviz images -t ├─<missing> Virtual Size: 967.0 B │ └─sha256:94df4 Virtual Size: 967.0 B Tags: hello-world:latest ├─<missing> Virtual Size: 122.0 MB │ └─<missing> Virtual Size: 122.0 MB │ └─<missing> Virtual Size: 122.0 MB │ └─<missing> Virtual Size: 122.0 MB │ └─sha256:2fa92 Virtual Size: 122.0 MB Tags: ubuntu:latest ├─<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: 0.0 B └─<missing> Virtual Size: 196.7 MB └─<missing> Virtual Size: 196.7 MB └─sha256:85961 Virtual Size: 196.7 MB Tags: centos:latest

@mikehaertl

This comment has been minimized.

mikehaertl commented Jun 13, 2016

@pnkjtr Since 1.10 the way layer IDs worked has changed fundamentally. For a lengthy explanation of this topic see #20399. There's also #20451 but I'm not sure, if this could be used by the nate/dockviz image.

Personally I find the way the new layers work very very confusing and much less transparent than before. And it's not really well documented either - AFAIK @tonistiigi's comments in the issue above are the only public explanation available. I'd be more than happy to be corrected on this one.

@arcseldon

This comment has been minimized.

arcseldon commented Aug 22, 2016

Unnecessary mistake.

@thangbn

This comment has been minimized.

thangbn commented Mar 16, 2017

this is a really useful feature. It a "core" feature for me. Love to see you guys bring it back.

@byronyi

This comment has been minimized.

byronyi commented Apr 24, 2017

For every single complaint here there're ten times more unspoken ones. This is not how you work on OSS docker.

@cpuguy83

This comment has been minimized.

Contributor

cpuguy83 commented Apr 24, 2017

Part of the reason for removal (beyond just being difficult to maintain) is it is tied to the (now old) method of image storage where images were all just a tree of layers and any layer is considered an image even if you can't actually run that layer.... in such a mess --tree (and external implementations of it) made sense to at least be able to make sense of it and know what can be cleaned and what cannot be.

Today images are flat. You have a proper thing that is an image and an image object is composed of layers (vs 1 layer = 1 image). Some images may share layers (so they only need to be downloaded/stored once) but there is no actual hierarchy.
Indeed you can have two images that are built from completely different sources (for instance, centos and debian) that can actually share layers based on the content of the layer rather than requiring the entire layer chain to be in common.

While you can build a tree view by comparing the layer chain in the image manifests, this would be an incomplete view of the relationship between images.

@abierbaum

This comment has been minimized.

abierbaum commented Apr 25, 2017

@cpuguy83 Is the newer way this works documented somewhere in the user docs? I haven't seen a full description but I may have missed it in the updated documentation.

The reason I ask is that for my use case of --tree I used it to see the hierarchy of images and the size of these images so I could optimize the size of the builds. We have multiple images used across multiple containers but we try to base them on common images during build so we can minimize the amount of data that has to be packaged and transferred. The tree view helped dramatically with that because I would see what images were built on what other images and where the big image "deltas" where in the build.

Based upon what you said above about images being flat, maybe this isn't a concern anymore. I haven't read anything that really describes this and I don't know of any tooling that allows me to view how the images are made up such that I can optimize for minimal packaging size of multiple related images. Can you point me in a direction that would help with this?

@cpuguy83

This comment has been minimized.

Contributor

cpuguy83 commented Apr 26, 2017

@abierbaum There's a fairly high-level doc here: https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/#content-addressable-storage

Note you can still get the size of images (in docker images), and even a summary view taking into account shared layers (docker system df).
Utilizing the content-hash with the image name can also improve your space requirements since you know that each build using a particular content hash are exactly the same.

@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Apr 27, 2017

docker history gives an overview as well for an image you built

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment