Bug 1735404

Summary: ConfigMap with binaryData is not handled correctly in kubectl get or oc extract
Product: OpenShift Container Platform Reporter: Clayton Coleman <ccoleman>
Component: ocAssignee: Sally <somalley>
Status: CLOSED ERRATA QA Contact: zhou ying <yinzhou>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.2.0CC: aos-bugs, jokerman, maszulik, mfojtik, somalley, tnozicka
Target Milestone: ---   
Target Release: 4.2.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: 2019-10-16 06:34:11 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 Clayton Coleman 2019-07-31 21:15:20 UTC
ConfigMaps with binaryData populated don't correctly count the number of keys from both data and binaryData in server side printing.

In addition, oc extract doesn't work on those config maps.

Comment 1 Clayton Coleman 2019-07-31 21:21:27 UTC
https://github.com/kubernetes/kubernetes/pull/80827

Comment 2 Maciej Szulik 2019-08-08 13:08:13 UTC
Sally we need to pick Clayton's PR into oc. Ping me for how :-)

Comment 3 Maciej Szulik 2019-08-20 07:54:40 UTC
Merged in https://github.com/openshift/oc/pull/63 moving to qa.

Comment 4 zhou ying 2019-08-22 09:00:51 UTC
Confirmed with latest oc version, the fix was missed :
[root@dhcp-140-138 yamlfile]# oc version --short 
Client Version: v4.2.0
Server Version: v1.14.0+5b18abc
OpenShift Version: 4.2.0-0.nightly-2019-08-21-210916


[root@dhcp-140-138 yamlfile]# oc get cm cmtest -o yaml 
apiVersion: v1
binaryData:
  bar: jmjKxUGNs/WqDQ==
data:
  foo: text value
kind: ConfigMap
metadata:
  creationTimestamp: "2019-08-22T08:49:11Z"
  name: cmtest
  namespace: zytest
  resourceVersion: "107431"
  selfLink: /api/v1/namespaces/zytest/configmaps/cmtest
  uid: b60f2f26-c4b9-11e9-b232-0a71a0132866
[root@dhcp-140-138 yamlfile]# oc extract cm/cmtest --to=-
# foo
text value

Comment 5 Sally 2019-08-27 21:25:09 UTC
I tested with oc downloaded from latest available nightly (openshift-client-linux-4.2.0-0.nightly-2019-08-27-105356/oc)
oc extract is returning binaryData.  Please test again to confirm.  Thanks!

$ oc version --short
Client Version: v4.2.0-alpha.0-29-g6788d4a0
Server Version: v1.14.0+1801aa8
OpenShift Version: 4.2.0-0.ci-2019-08-26-085534

$ oc get cm cmtest -o yaml
apiVersion: v1
binaryData:
  bar: jmjKxUGNs/WqDQ==
data:
  foo: text value
kind: ConfigMap
metadata:
  creationTimestamp: "2019-08-27T21:05:58Z"
  name: cmtest
  namespace: bztest
  resourceVersion: "516496"
  selfLink: /api/v1/namespaces/bztest/configmaps/cmtest
  uid: 77c17e06-c90e-11e9-b72c-0658239c1cdc

$ oc extract cm/cmtest --to=-
# foo
text value
# bar
�h��A����

Comment 7 zhou ying 2019-08-28 01:39:36 UTC
Sally :

     Thanks for feedback, I double confirmed , when use oc extract from nightly build we can extract the binarydata correctly:
[root@dhcp-140-138 ~]# oc extract cm/cmtest -n openshift-config --to=-
# foo
text value
# bar
�h��A����


But use oc installed by the yum repo, still miss the binaryData:
[root@dhcp-140-138 ~]# oc version 
Client Version: version.Info{Major:"4", Minor:"2+", GitVersion:"v4.2.0", GitCommit:"09eb70949", GitTreeState:"clean", BuildDate:"2019-08-27T22:29:56Z", GoVersion:"go1.12.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.4+4b86cc5", GitCommit:"4b86cc5", GitTreeState:"clean", BuildDate:"2019-07-24T19:42:25Z", GoVersion:"go1.11.6", Compiler:"gc", Platform:"linux/amd64"}
OpenShift Version: 4.1.8

[root@dhcp-140-138 ~]# oc get cm cmtest -n openshift-config -o yaml 
apiVersion: v1
binaryData:
  bar: jmjKxUGNs/WqDQ==
data:
  foo: text value
kind: ConfigMap
metadata:
  creationTimestamp: "2019-08-28T01:25:03Z"
  name: cmtest
  namespace: openshift-config
  resourceVersion: "229540"
  selfLink: /api/v1/namespaces/openshift-config/configmaps/cmtest
  uid: a94c1cc8-c932-11e9-9ad5-024af6bb4588
[root@dhcp-140-138 ~]# oc extract cm/cmtest -n openshift-config --to=-
# foo
text value

Comment 8 Sally 2019-08-28 15:21:04 UTC
Ah, I see, thanks for the info.  The rpm is indeed a bit behind (It shouldn't/won't be in near future, but with the recent split of oc from origin this is a side-effect).  The rpm should be up-to-date by tomorrow.  Since I've confirmed the recent payload has the fix, I'm confident there's nothing more to do on our end.  Please confirm the fix in the oc extracted from the latest payload, such as: https://openshift-release.svc.ci.openshift.org/releasestream/4.2.0-0.ci/release/4.2.0-0.ci-2019-08-28-123746   
Thanks!

Comment 10 zhou ying 2019-08-29 02:18:51 UTC
Using oc extracted from 4.2.0-0.nightly-2019-08-28-235925, can't reproduce the issue:
[root@dhcp-140-138 ~]# oc get cm cmtest -o yaml 
apiVersion: v1
binaryData:
  bar: jmjKxUGNs/WqDQ==
data:
  foo: text value
kind: ConfigMap
metadata:
  creationTimestamp: "2019-08-29T02:17:00Z"
  name: cmtest
  namespace: zhouytm
  resourceVersion: "731052"
  selfLink: /api/v1/namespaces/zhouytm/configmaps/cmtest
  uid: 15724363-ca03-11e9-9fdd-06aa25ffd4c6
[root@dhcp-140-138 ~]# oc extract cm/cmtest --to=-
# foo
text value
# bar
�h��A����
[root@dhcp-140-138 ~]# oc version
Client Version: version.Info{Major:"", Minor:"", GitVersion:"openshift-clients-4.2.0-201908281419", GitCommit:"372c08a6a95e4ecc7c61dd16052fc12f6bca376c", GitTreeState:"clean", BuildDate:"2019-08-28T19:10:30Z", GoVersion:"go1.12.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.0+e12dd85", GitCommit:"e12dd85", GitTreeState:"clean", BuildDate:"2019-08-27T23:04:55Z", GoVersion:"go1.12.8", Compiler:"gc", Platform:"linux/amd64"}

Comment 11 errata-xmlrpc 2019-10-16 06:34:11 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-2019:2922