why two flags its not really scalable...

I'm 👎 to the solution, but I acknowledge the problem.

There are a couple possibilities that might be better suitable to solve the problem:

1. Since we acknowledge that a container and an image can have the same name, we can argue that we should always perform the two calls. This is probably the easier solution, 0 flags needed. We can be slightly fancy and try to detect whether the argument is a container id or not, and only send the container request in the first case.
2. If we don't want to send two requests every time, we can add a --all flag and do what I propose in 1 when the flag is enabled.

@calavera
we contemplated that option but we felt it can present an awful lot of information to user.
e.g. docker inspect --all arg1 arg2 arg3 ..... argN can show N * 2 JSON to the user, whereas all user wanted was to see the image JSON which were being shadowed by the container JSON, since they shared the same name.

What if we do --image and --container, but make them both true by default.

No 2 flags!!!

On Wednesday, May 13, 2015, Brian Goff [email protected] wrote:

What if we do --image and --container, but make them both true by default.

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

Ok, --type

oh man, can we please consider just adding a new command: docker inspecti ... like we have docker rmi .... I'm not thrilled with just adding an 'i' to the end of the command but at least we're consistent and it would then be very clear what we're talking about.

I don't really understand the argument against two arguments. It is not like the docker inspect has a whole ton of options now. Originally we were going to use just --image-only, but then why couldn't you ask for only container matches.

Bottom line is we have bug reports from people trying to look at images with the same name as a container, and we want a simple way for the users to be able to examine them without having to understand where to search for the UUid field in a container json file.

I actually hate rmi versus rm, but I guess that somewhat follows the standard of rm versus rmdir.

If we went with this behaviour we should break existing behaviour for consistency.

This seems like a simple fix, but simple fixes often bring out Bike Shedding arguments.

It's a UI decision I know the struggle with it being the same name but two
flags is imo dumb and doesn't scale

On Thursday, May 14, 2015, Daniel J Walsh [email protected] wrote:

I don't really understand the argument against two arguments. It is not
like the docker inspect has a whole ton of options now. Originally we were
going to use just --image-only, but then why couldn't you ask for only
container matches.

Bottom line is we have bug reports from people trying to look at images
with the same name as a container, and we want a simple way for the users
to be able to examine them without having to understand where to search for
the UUid field in a container json file.

I actually hate rmi versus rm, but I guess that somewhat follows the
standard of rm versus rmdir.

If we went with this behaviour we should break existing behaviour for
consistency.

This seems like a simple fix, but simple fixes often bring out Bike
Shedding arguments.

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

@jfrazelle what do you mean by 2 flags doesn't scale ?
Can you give an example or scenario ?

Not sure how adding additional commands scales better then adding options. I would argue the exact opposite.

Adding 2 flags that are super specific to 1 thing is "not scalable" because
now if you inspect anything other than images or containers in docker, whoa
look we need to add a new flag for that too

But honestly I don't want to fight about this, do what you want, see what
happens when users think docker is hard to use because we have a bajillion
flags, each one does 1 thing

On Thursday, May 14, 2015, Daniel J Walsh [email protected] wrote:

Not sure how adding additional commands scales better then adding options.
I would argue the exact opposite.

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

Also I'm definitely -1 on a inspecti, rmi is awful and we should not go
down that road again, the only ok example given here was --type because at
least we can add more things to inspect in the future without a new flag
for each one

On Thursday, May 14, 2015, Jessica Frazelle [email protected] wrote:

Adding 2 flags that are super specific to 1 thing is "not scalable"
because now if you inspect anything other than images or containers in
docker, whoa look we need to add a new flag for that too

But honestly I don't want to fight about this, do what you want, see what
happens when users think docker is hard to use because we have a bajillion
flags, each one does 1 thing

On Thursday, May 14, 2015, Daniel J Walsh <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

Not sure how adding additional commands scales better then adding
options. I would argue the exact opposite.

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

@jfrazelle
boolean flags are binary {true/false, 0/1} in nature. If that is your concern, then @cpuguy83 suggested --type flag which would be a string flag and can take all kind of values.

I understand your concern and its a valid one, but IMHO docker inspect really doesn't have that many flags to begin with. n the use-case is legitimate.

I am fine with --type=image or --type=container.

The only way a new flag helps, IMO, is if its mandatory. W/o it being required we’re then
still left with the current mess of the code guessing as to what the user intended to take action
on. That’s just a horrible design. While “rmi” and “inspecti” are not my favorite things,
at least its unambiguous and no room for confusion.

Ideally, I would have preferred if we had “docker container inspect” and “docker image inspect”
but that’s another discussion.

On May 14, 2015, at 7:25 AM, Jessie Frazelle [email protected] wrote:

Also I'm definitely -1 on a inspecti, rmi is awful and we should not go
down that road again, the only ok example given here was --type because at
least we can add more things to inspect in the future without a new flag
for each one

On Thursday, May 14, 2015, Jessica Frazelle [email protected] wrote:

Adding 2 flags that are super specific to 1 thing is "not scalable"
because now if you inspect anything other than images or containers in
docker, whoa look we need to add a new flag for that too

But honestly I don't want to fight about this, do what you want, see what
happens when users think docker is hard to use because we have a bajillion
flags, each one does 1 thing

On Thursday, May 14, 2015, Daniel J Walsh <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

Not sure how adding additional commands scales better then adding
options. I would argue the exact opposite.

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

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

I think there is a real use case for adding a flag for this, I've hit numerous times w my irssi container

@jfrazelle @calavera @rhatdan
I have updated the code and docs.

design LGTM thanks

Thanks @shishir-a412ed ! Added some comments inline.

Also, this needs documentation in the online reference as well; https://github.com/docker/docker/blob/master/docs/reference/commandline/inspect.md

@moxiegirl @thaJeztah I have made the changes.
Let me know if I missed anything.

LGTM, thanks for being patient, @shishir-a412ed, I know it took a while!

ping @moxiegirl

Kicked experimental build, ready to merge if that passes

@thaJeztah Sounds good !

\o/ merged!

Woo Hoo