Rename kn service describe to kn service show

[rhuss]

Why ?

• show is shorter and easier to write than describe
• We already moved away from kubectl semantics when we switched from get to list and list won't return ever a singe element (but potentially a list with one element)
• We can add a -o json etc. to kn service show to allow retrieving the definition of a single service (not possible right now) without adding more confusion between kubectl describe service (no -o option) and a kn service describe (with then maybe an -o options).

[zhangtbj]

How about change describe to get? I think it is shorter and more standard.

like kn route get helloworld

I see most of cli use get to show the detail info, but I think less use show, hope it is helpful :)

[rhuss]

get is really kind of "burned" as it has a special meaning for "kubectl" (where it corresponds to our "list"). For kubectl it doesn't show you the details.

So I think we should either follow the kubectl semantics (with get & describe) or, in order to avoid any confusion complete deviate from it (hence the suggestion with list & show).

[zhangtbj]

oh i see, thanks for clarify.

I think if the result is same as kubectl, we can use the same get or describe

If the result is different, we should use the different subcommands like show or list to avoid the confusing.

[rhuss]

Yes, it's different:

• kubectl get returns either a list (without or argument) or a single object (with name) argument. This is very confusing (i.e. that get returns a list and that in different formats), so that we decided to always return a list with list. Otherwise you have the same options for machine readable output (e.g. -o yaml).

• kubectl describe always show a human readable output, but does not support creating machine readable output -o yaml. Since kn list removed the option to get a single object, the idea was to allow -o yaml to kn show (as it is now different than describe).

That whole mapping is a mess, so I really believe the more we can differentiate us from kubectl the better. There already other differences like kn <noun> <verb> vs. kubectl <verb> <noun>, so let's make the difference clear by non-overlapping verbs for where kn and kubectl differs.

[rhuss]

Closing this issue in favour of kn service describe as it has been decided. RIP // @duglin (that the issue I referred to)