Change "get" to "list"

[duglin]

Proposal: change get to list

When people want to list the set of services running I think kn service list is more natural for people. I know this is more of a personal preference kind of thing, especially when you consider that kubectl actually uses get for both (lists and singular), but if you think about how all of the kn service verbs act on a single instance of a service, get would therefore imply "get me info about A service". While, the word list more naturally implies you want a "list" of something back.... in this case services.

Net: change it to: kn service list to see all services.

Same should apply to the other nouns as well.

[rhuss]

FYI, we already had the reverse discussion starting at #48 (comment) and decided in the WG meeting on 2019-04-23 to go with get over list (to be in alignment to kubernetes and following the principle of least surprise even when we do not 100% like the way kubectl does it).

We can revisit this decision, but at the moment get is mostly for an overview and machine-readable output (like with -o yaml) and describe for human-readable detail output of a single service (like in kubectl).

[duglin]

I wouldn't compare things to kubectl since kubectl is kind of odd in this respect. Sometimes it GETs a single thing, sometimes it GETs multiple - then add in the optional "s" at the end of the resource type - and I wouldn't call it the most UX-friendly. I view kn (like knative) as a better UX thank vanilla Kube. So I was hoping we could do better than the CRUD-like interface of kubectl.

[rhuss]

I went now back and forth with this UX issue, and I tend to agree with @duglin Although I still think that the 'principle of least suprise' is still a good thing, I'm by no means sure anymore whether it applies to kubectl vs. kn:

• kn and kubectl are already called differently: (kubectl) vs (kn). Adding a similar behaviour afterwards for "get" is probably much more confusing than to make a clear cut.
• Also some code is shared (i.e. the one for machine readable output), the target audience is different enough to justify a different UX style, too.

As I had now the chance to play around quite a bit with kn, I'd like to make the following suggestion for a kind of compromise, but still with a clear theme:

• kn service list <filter> for listing plain services. The filter should be a "contains" or "prefix" filter so that kn serivce list <name> will return exactly the single service. This is similar to kubectl get kservice, but with a clear focus on the "listing"
• kn service get <name> allows a single argument, the name of a service. The default output is machine readable (json or yaml). It can be nicely used in scripts. It reflects a pure "get" semantics as known from CRUD.
• kn service show <name> a pure human readable output (which could be tuned with options for different layouts, see feature(service describe): Output of service details [vanilla, color, hipster] #75 ). It alos contains summaryt information about other related objects (like revisions belonging to this sercice, traffic targets, ...). So it's deliberately named different than a kubectl describe service to make it clear.

My feeling is that these three read-only commands would cover all use cases (searching/listing, getting a json for scripting, human readable output in different flavors) in a nicely separated way.

Wdyt ? Would it be worth to reconsider our initial decision to kn service get over kn service list ?

[duglin]

No surprise :-) but I agree with the "list" and "get" parts. I'm not as sure about the "show" one because that feels like a variant of "get", just with a different output format. So, I'd opt to assume humans are our first set of users and that means kn service get <name> should show things in a human readable format by default, but if they specify a flag then they'll get the machine readable version of the same type of output.

btw, I think this same type of flag on kn service list would be good too. I like the idea of adding an -o yaml/json type of flag to most commands so Kn users can easily take what they do by-hand and then turn around and use it in a script by just adding a flag.

[navidshaikh]

IMO, we should keep only two verbs for readonly listing of resources,

• (as per proposal) list:
  1 - Listing all items of a kind
  2 - Filtering by item name as argument
  3 - Applying machine readable output flags to above two, returning list or single object (-o yaml|json| etc)

• feature(service describe): Output of service details [vanilla, color, hipster] #75 describe: For descriptive output of the item

[evankanderson]

list also needs a human-readable output (e.g. a tabular format).

[sixolet]

The command line we're building is primarily for humans, and there's always -o yaml if you're a robot. I too find myself annoyed by typing get when I mean list. I'm for changing it back.

…

On Jun 11, 2019, at 1:58 PM, Evan Anderson ***@***.***> wrote: list also needs a human-readable output (e.g. a tabular format). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[duglin]

thanks y'all!