Deprecate 'docker images --tree' and 'docker images --viz' #5001
Conversation
* 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)
|
@shykes what about the tests around these features and moving forward with your other PR? Are they still going to cause issues for you? |
|
LGTM |
1 similar comment
|
LGTM |
Deprecate 'docker images --tree' and 'docker images --viz'
|
Sad to see |
|
Agreed. Very sad to see this go. --tree made "docker images" much more useful. |
|
Bummer. As the author of those two features, I'm sad to see them removed. I used 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:
Thanks for any help you can give. |
|
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? |
|
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. |
|
That would work for me. Would the debug option be added to other commands too? Thanks. |
|
I think the raw output would be enabled for all commands |
|
Cool. How can I help? I can try to put together a PR for the debug flags if that would be useful. |
|
I like the idea |
|
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. |
|
Great On Mon, Apr 21, 2014 at 9:17 PM, Nate Jones notifications@github.comwrote:
Victor VIEUX |
|
I feel like, for this, some of the client side api of docker's code could be opened up a little. Like the I prototype of this https://github.com/vbatts/docker/compare/vbatts-docker_tool and https://gist.github.com/vbatts/60ffdd3df308d1c13967 |
|
What a dumb move. |
|
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). |
|
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. |
|
I'd suggest that --tree should stay alone for the benefit of new users and ease of use. |
|
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. |
|
@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? |
|
@thaJeztah i am still very fond of the idea for |
|
@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? |
|
Ideally plugins will use libchan, which is a better path than just shelling On Sat, Nov 8, 2014 at 6:10 PM, Sebastiaan van Stijn <
|
|
Ok, fair. Just saw this as a nice way to bring back some things to docker :) |
|
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? |
|
+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. |
|
+1 to bring back this feature! we need it!!! It's really inconvenient without it. |
|
+1 bring it back |
|
So it's unanimous. +1 to add it back into the core. |
|
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. |
|
https://github.com/shaded-enmity/docker-doug To list images depending on IMAGE_NAME |
|
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. |
|
I have recently released a new version of sen (terminal user interface for docker engine) which contains interactive https://github.com/TomasTomecek/sen/blob/master/docs/features.md#image-tree |
|
That looks like an awesome project! Thank you for sharing. |
|
@TomasTomecek very cool! |
|
anyone get this? windows 8.1 |
|
Hey @meffect, just need to add And, for anyone that has issues with dockviz, please file an issue over there. Thanks. |
|
thanks it works
|
|
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 |
|
re-submitting the exact o./p again. I am getting in output of 'dockviz images -t' command. |
|
@pnkjtr I edited your last comment to put the output in a code-block (otherwise the |
|
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 ?
|
|
@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 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. |
|
Unnecessary mistake. |
|
this is a really useful feature. It a "core" feature for me. Love to see you guys bring it back. |
|
For every single complaint here there're ten times more unspoken ones. This is not how you work on OSS docker. |
|
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 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. 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. |
|
@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? |
|
@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 |
|
|
|
If you're on Windows, I wrote a simple tool for myself to do this https://github.com/aloneguid/docker-explorer-windows |
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.