what about containers that have that image the distant history? e.g. the image in question was used to make another image and that's 2nd image is the one used to create the container.

Ah 😝, this would make it way more complicated to implement then 😅, and I'm not sure how you would handle from a user point of view.

Given that it was implement
And I have 3 images : base -> middle -> final
When I'm doing ``--filter=image=middle``
Then should it filter all containers based on middle and final, or just those with final ?

I think the simpler the better (just filter with the image used when starting the container). And I don't really see a use case for distant history — I might be wrong though.

I only see (potential) value is we walk the ancestry tree, the easy case I can pretty much grep :-( Not convinced.

@icecrime On the other hand I'm not convinced on the grep part 😊 (although I like grep a lot 😺). There is a few cases where I wouldn't find grep useful:

• Same or common part of the name shared by some images and some containers :

$ docker ps -a | grep busybox
5c33c99ac89f        busybox         […]                         toto                
5ba009755259        maven           […]                         busybox1            
2aff61195a5a        maven           […]                         busybox  

• The ability to chain it. Let's say I want to stop all container based on the busybox images : with the filter it would be docker ps -aq --filter=image=busybox | xargs docker stop, without docker ps -a | grep busybox | awk '{ print $1 }' | xargs docker stop (but as seen in the previous point I could get false positive).

I do agree these are probably edge cases and might not happen a lot in real life or not that much but it felt so easy to implement.

I also do see potential on the "walk the ancestry tree" but I'm not sure how it would look in a user point of view. Question like :

• Do I always want to walk the ancestry tree (and this, filtering on a base image would return all container running these or images based on it) or not ?
• If not, how would I do to specify it needs to walk the tree or not ? (like --filter=image=debian&children)
• Is there a real use case for that ? I don't know but maybe.

I only see the ancestry usecase as being interesting so no need for a flag to say "look at entire history", it should do it automagically.

I can see use cases for taking ancestry when filtering, but I really wonder if this is what I would expect if I filter name=foo. I think I would expect to only get containers started from foo. Perhaps another flag to include ancestry?

sorry name=foo should obviously be image=foo in my previous comment :-)

the reason I'm not sure "image=foo" is that interesting is because there isn't much of a difference between:

docker run -ti ubuntu some-command

and

docker build -f Dockerfile-FROM-ubuntu+some-command ...
docker run ...

I guess it might be a little useful to have: image=foo and ancestor=foo but I wonder how quickly people will opt for the ancestor variant once they realize they really want to look for more than the immediate parent image.

but I wonder how quickly people will opt for the ancestor variant once they realize they really want to look for more than the immediate parent image.

True, in many cases, either immediate parent or "uses" an image are what you're looking for. From a UX perspective though, I'm really against calling the "ancestor" filter "image", because it doesn't reflect the intent and will definitely lead to a lot of support questions / invalid bug reports.

We can opt for not implementing immediate parent (for now) and only implement ancestor search once people start asking for it. Perhaps an easier name for the filter, would "inherits" be a good name? --filter inherits=ubuntu:14.04

To the filtering itself, what kind of searches should be supported? A quick list;

• image
• image:tag
• image:tag@digest
• short-id
• full-id

I definitely +1 to more filters.
Grep is nice, but not particularly nice in this case.

Collective review

@duglin @calavera @tonistiigi

We would prefer the tree-traversal implementation instead of just filtering with a direct parent image name.

Because in the inspect output, Image refers to the direct parent image, we should not call the filter image, and we suggest ancestor instead (less ambiguous).

As for answering #14570 (comment), we should support all of the input forms. They will have to be mapped to a full image ID anyways.

Let's leave the "direct-parent-only" implementation for another time, as we seem to agree the tree-traversal is more useful.

SGTM, thanks!

looks good, just one question.

Oh I though I pushed the docs (which are quite small) but didn't.. 😅. /cc @thaJeztah

Updated with to take care of @duglin and @thaJeztah comments, I think 😅.

docs LGTM, as discussed with @vdemeester, examples will be added in a filtering chapter/section #14570 (comment)

@vdemeester LGTM

Moving to docs review.

LGTM per my previous comment #14570 (comment)

ping @moxiegirl, looks like we merged the "follow up" before the one it's "following up" 😄

@thaJeztah yay 😅 😝

This is why I should leave the merging to others (@thaJeztah) ...

@moxiegirl counting that as a LGTM, merging!

🎉 😉