Bug 1505796 - `oc get -o=custom-columns` should display <no value> or empty for objects lacking the field
Summary: `oc get -o=custom-columns` should display <no value> or empty for objects lac...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.8.0
Assignee: Juan Vallejo
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-24 10:13 UTC by Xingxing Xia
Modified: 2018-03-28 14:08 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-28 14:08:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0489 0 None None None 2018-03-28 14:08:33 UTC

Description Xingxing Xia 2017-10-24 10:13:01 UTC
Description of problem:
When some objects lack the field, `oc get -o=custom-columns` exits with error and has no any object output
For better UX, it should still work and is suggested to display <no value> or empty for the lacked field in those objects

Version-Release number of selected component (if applicable):
oc v3.7.0-0.175.0

How reproducible:
Always

Steps to Reproduce:
Note, below just use clusterserviceclass as example. In fact, can use any resource type to reproduce the issue, as long as some objects have but some others lack the field
1. Check objects with concerned columns
1) 2 columns
$ oc get clusterserviceclass -o=custom-columns="name:.metadata.name,display name:spec.externalMetadata.displayName"

2) Add a third concerned column, which is lacked in some object
$ oc get clusterserviceclass -o=custom-columns="name:.metadata.name,display name:spec.externalMetadata.displayName,provider:spec.externalMetadata.providerDisplayName"

3) As comparison, run above "2)" command only upon one object that does have all concerned columns
$ oc get clusterserviceclass ba4d24f1-b7c2-11e7-8556-fa163e25cbb7 -o=custom-columns="name:.metadata.name,display name:spec.externalMetadata.displayName,provider:spec.externalMetadata.providerDisplayName"

2. As comparison with above "2)", run another approach for columns
$ oc get clusterserviceclass --template="{{range .items}}{{.metadata.name}}       {{.spec.externalMetadata.displayName}}       {{.spec.externalMetadata.providerDisplayName}}
{{end}}" # note, before {{end}}, has a newline

Actual results:
1.
1) It succeeds and outputs:
name                                     display name
ba4d24f1-b7c2-11e7-8556-fa163e25cbb7     CakePHP + MySQL (Persistent)
ba6393fe-b7c2-11e7-8556-fa163e25cbb7     Pipeline Build Example
ba655233-b7c2-11e7-8556-fa163e25cbb7     MongoDB (Persistent)
...snipped other objects...

2) When some object (here, "Pipeline Build Example") lacks the field, it does not output any object, it fails and outputs:
error: providerDisplayName is not found

3) It succeeds

2. Instead of fails, it succeeds and has placeholder "<no value>":
ba4d24f1-b7c2-11e7-8556-fa163e25cbb7       CakePHP + MySQL (Persistent)       Red Hat, Inc.
ba6393fe-b7c2-11e7-8556-fa163e25cbb7       Pipeline Build Example       <no value>
ba655233-b7c2-11e7-8556-fa163e25cbb7       MongoDB (Persistent)       Red Hat, Inc.
...snipped other objects...

Expected results:
1.2: for better UX, it should be like step 2, i.e. still work when hitting objects lacking the field. It can display <no value> or empty for these objects lacked field

Additional info:

Comment 1 Juan Vallejo 2017-10-24 15:59:44 UTC
Origin PR: https://github.com/openshift/origin/pull/17023

Comment 2 Xingxing Xia 2017-10-26 07:02:36 UTC
Verified in oc v3.7.0-0.179.0, now <none> is placed for lacked/unknown field:
$ oc get clusterserviceclass -o=custom-columns="name:.metadata.name,display name:spec.externalMetadata.displayName,provider:spec.externalMetadata.providerDisplayName"

name                                   display name                       provider
997d1b7f-b9fa-11e7-b315-fa163eef4e51   Jenkins (Ephemeral)                Red Hat, Inc.
998040aa-b9fa-11e7-b315-fa163eef4e51   Pipeline Build Example             <none>
9984a670-b9fa-11e7-b315-fa163eef4e51   Django + PostgreSQL (Persistent)   Red Hat, Inc.
9987a6fb-b9fa-11e7-b315-fa163eef4e51   Node.js + MongoDB (Persistent)     Red Hat, Inc.
998a3860-b9fa-11e7-b315-fa163eef4e51   MongoDB (Persistent)               Red Hat, Inc.
998e297a-b9fa-11e7-b315-fa163eef4e51   MariaDB (Persistent)               Red Hat, Inc.
99b26cba-b9fa-11e7-b315-fa163eef4e51   MySQL (Persistent)                 Red Hat, Inc.
99f00fc4-b9fa-11e7-b315-fa163eef4e51   PostgreSQL (Persistent)            Red Hat, Inc.
99f35132-b9fa-11e7-b315-fa163eef4e51   CakePHP + MySQL (Persistent)       Red Hat, Inc.
9a6a4b34-b9fa-11e7-b315-fa163eef4e51   Dancer + MySQL (Persistent)        Red Hat, Inc.
9a77eeb8-b9fa-11e7-b315-fa163eef4e51   Rails + PostgreSQL (Persistent)    Red Hat, Inc.
9b04d46a-b9fa-11e7-b315-fa163eef4e51   Jenkins (Persistent)               Red Hat, Inc.

Comment 5 errata-xmlrpc 2018-03-28 14:08:09 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0489


Note You need to log in before you can comment on or make changes to this bug.