service get

[knative]

service get

[sixolet]

I think one thing I don't like about kubectl is the fact that get works on two different cardnalities.

Operation	Cardnality	kubectl	current kn
Summary	One	get	n/a
Summary	Many	get	list
Detail	One	describe	describe
Detail	Many	n/a	n/a

[csantanapr]

/milestone v0.1.0

[knative-prow-robot]

@csantanapr: You must be a member of the knative/knative-milestone-maintainers github team to set the milestone.

In response to this:

/milestone v0.1.0

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[navidshaikh]

@csantanapr : what information about <service_name> should be printed in this command ?

How does this defer from kn service list?

If we can list the data points to be provided by CLI for these two commands, it should help.

[rhuss]

I would like to suggest to combine kn service list and kn service get to a single command kn service get for the following reasons:

• It reduces the UX surface by having one subcommand less. This is IMO always a good thing. kn service get without argument can just list all services.
• It mimics the behaviour of kubectl get where kubectl get without argument just list all resources. So having only kn service get also follows the Principle of least astonishment which is a good thing.

Wdyt ?

If there are no objections, I'd like to start working on kn service get

[rhuss]

Another argument for having a single 'kn service get' for listing and showing is a typical ux flow:

• List all service available
• Then: Select a single service to get details.

So you can call 'kn service get', check the output, cursor up for one step back in shell history and then just add the service of interest to the end of the command.

[cppforlife]

@rhuss downside to combining list and get is that i imagine output format would be quite different. list i imagine is more compact whereas get would show more detailed information.

[sixolet]

I like having different list and single-object describe commands. Get vs describe, no particluarly strong opinion about the single-object one, but I do like describe.

[rhuss]

@sixolet +1, I think too that we should distinguish between get and describe a la kubectl.

I think we could just rename kn service list to kn service get and allow an argument for filtering on the list. That would be similar to kubectl get (and hence less surprising).

kn service describe would be reserved then for a detail view of a single service.

Wdyt ?

Of course it depends how close we want to follow a UX like for kubectl. I think it would be good to stay close to its UX (get for list/summary like info, describe for details) because people know this already. On the other hand when changing to something new, then I would do it for all verbs. I.e. change also describe to something else, like show or info(so, list for list/summary and show for details, new for create).

[rhuss]

@rhuss downside to combining list and get is that i imagine output format would be quite different. list i imagine is more compact whereas get would show more detailed information.

@cppforlife I'm not sure whether the output format should be different, if we want to keep the semantics of get in kubectl (which actually is a list command there).

Operation	kubectl style	kn style	alternate style
Summary info	get	list	list
Details info	describe	describe / (get now ?)	show

[rhuss]

I suggest #75 for the start of implementation for this issue with kn service describe is about presenting the detail information (instead of kn service get).

[sixolet]

(I'm ok with implementing a single-target summary information printing command, but it should be different from the many-target summary-information printing command)

[rhuss]

(I'm ok with implementing a single-target summary information printing command, but it should be different from the many-target summary-information printing command)

For get (or list right now) we are supporting the printing option -o from cli-runtime, which treats single entities and a list of entities the same as it e.g. for yaml/json exports either a single object or a list of objects, but with the same content. Same for -o name.

In that sense and for staying consistent, I tend to lean to keep the one and many information the same also for 'human readable' output for kn get (i.e. using a list with a single entry).

What would be a plus though would be to allow multiple and wildcard arguments for kn service get to filter the list (see #71 )

[sixolet]

Done by #90