openshift-online/ocm-cli

Flag --columns api.url returns incorrect API url

Closed this issue · 6 comments

apodhrad commented

The following command works correctly

ocm list cluster --parameter search="name='osd4-153'"

and returns correct ID, NAME, API URL and other columns.
Where API URL is https://api.osd4-153.fneg.s1.devshift.org:6443

But when I request a specific column by

ocm list cluster --parameter search="name='osd4-153'" --columns api.url

then I receive only shorter API URL, namely https://api.osd4-153.fneg.s1.dev

OCM Version: 0.1.47
OS: Fedora 33 x86_64

cben commented

Yes, columns are currently truncated.
You can control width e.g. --columns api.url --padding=100.
But I agree, silently truncating is a bug / mis-feature. Better options when a field is wider than allocated column width:

  1. at least could indicate it's truncated, e.g. with ellipsis char?
  2. break alignment but include full value!
    • con: output is no longer machine-parsable. Meh. Knowing expected positions e.g. cut --characters=40-59 is fragile anyway. And who needs machine-parsable format when the data is truncated?
    • con: truncating is useful to fit an "overview" of data into terminal width. However, piping to less -S and scrolling horizontally is more flexible (you need this anyway for default columns).
  3. use Tab characters between columns; pad with spaces (before the tab) to align to given width, but allow wider texts.
  4. increase column width to fit! However, this requires buffering the whole output; ocm list cluster is getting a "page" at a time from the API and currently showing them as they come, buffering it all can take a long time so is not good default.

IMHO (3) is best option.

  • Pro: More parsable than current output.
  • Pro: Users that want (4) and willing to wait for full output can pipe to filters like | column --table --separator=$'\t' or https://github.com/BurntSushi/tabwriter.
cben commented

After thinking some more: machine-readable table output is a non-goal, using tabs to encourage it might actually be a dis-service to users!? That's what JSON is for.
So (2) is also fine choice: break alignment, if user cares they'll re-run with wider --padding.
(That said, we should keep tweaking default column widths & order to usually look good => #262 is a step forward.)

cben commented
  • I see only ocm list commands do pagination but have no json output. We should add --jsonlines or something like that, independently of what we decide in this issue.
cben commented

Responding to a ideas by @T0MASD from related issue on internal tracker:

would it make sense to never pad the data when --columns flag is used?

You mean always have fixed 1 or 2 spaces between columns, and not even attempt alignment? It's doable, but IMHO would be a worse default.

  • Pro: doesn't pretend columns are reliable when they really are not.
  • Con: harder to scan visually? ocm list commands are primarily targetted at humans.
  • Con: Specifically when a blank field is followed by non-blank fields, it's hard for humans to count spaces and figure out which field it is. It's easier with a (mostly) aligned table.

I think truncating fields makes sense when running something like ocm login which has "template" of fields to display

My argument is that looking at this project's history, we've repeatedly been wrong about default width, and got several complaints about truncating confusing users.
So I disagree, even when we have fixed "template", I feel "soft fail" of breaking alignment is better UX than "hard fail" of truncating.

jhernand commented

The CLI has been recently changed so that it has a width explicitly specified for certain output columns, in particular for the api.url column of the clusters table it is 58 characters. See the pkg/output/tables/clusters.yaml file:

columns:
- name: api.url
  header: API URL
  width: 58
  ...

That is respected regardless of the value of the --columns option, and doesn't need the --padding option. This is the result for this particular use case:

$ ocm list clusters --parameter search="name like 'xxx-yyy-%'" --columns api.url
API URL
https://api.xxx-yyy-aaaaaaa.a0b1.z1.openshiftapps.com:6443
https://api.xxx-yyy-bbbbbbb.a0b2.z1.openshiftapps.com:6443
https://api.xxx-yyy-ccccccc.a0b3.z1.openshiftapps.com:6443
https://api.xxx-yyy-ddddddd.a0b4.z1.openshiftapps.com:6443
https://api.xxx-yyy-eeeeeee.a0b5.z1.openshiftapps.com:6443

I think that solves this particular issue, so I'd suggest to close it.

jhernand commented

The fix for this issue was included in release 0.1.55.