Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1505796

Summary: `oc get -o=custom-columns` should display <no value> or empty for objects lacking the field
Product: OpenShift Container Platform Reporter: Xingxing Xia <xxia>
Component: ocAssignee: Juan Vallejo <jvallejo>
Status: CLOSED ERRATA QA Contact: Xingxing Xia <xxia>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.7.0CC: aos-bugs, ffranz, jokerman, jvallejo, mmccomas, wmeng
Target Milestone: ---   
Target Release: 3.8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-28 14:08:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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