Bug 1529482 - "factory_object_mapping.go ... Unable to get a discovery client to find server resources" when prompting "the server doesn't have a resource type"
Summary: "factory_object_mapping.go ... Unable to get a discovery client to find serve...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.9.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: 3.11.z
Assignee: Maciej Szulik
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-28 10:31 UTC by Xingxing Xia
Modified: 2019-04-11 05:38 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-11 05:38:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0636 0 None None None 2019-04-11 05:38:28 UTC

Description Xingxing Xia 2017-12-28 10:31:57 UTC
Description of problem:
Meet the info "factory_object_mapping.go ... Unable to get a discovery client to find server resources" when prompting "the server doesn't have a resource type"

Version-Release number of selected component (if applicable):
oc/OCP v3.9.0-0.9.0

How reproducible:
Always

Steps to Reproduce:
1. oc login to server
oc version
oc v3.9.0-0.9.0
kubernetes v1.8.1+0d5291c
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://MASTER:8443
openshift v3.9.0-0.9.0
kubernetes v1.8.1+0d5291c

2. run `oc get svc --user=no-this-user --loglevel=6`

Actual results:
2. It outputs:
I1228 05:20:03.253275  121061 loader.go:357] Config loaded from file /home/xxia/.kube/config
I1228 05:20:03.253487  121061 factory_object_mapping.go:83] Unable to get a discovery client to find server resources, falling back to hardcoded types: auth info "no-this-user" does not exist
F1228 05:20:03.253696  121061 helpers.go:119] the server doesn't have a resource type "svc"

As comparison, run step 2's command with oc/OCP v3.9.0-0.8.0, it'll give good info, as before.
$ oc version
oc v3.9.0-0.8.0
kubernetes v1.8.1+0d5291c
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://MASTER:8443
openshift v3.9.0-0.8.0
kubernetes v1.8.1+0d5291c

$ oc get svc --user=no-this-user --loglevel=6
I1228 05:20:08.471554  110834 loader.go:357] Config loaded from file /home/xxia/.kube/config
F1228 05:20:08.471859  110834 helpers.go:120] error: auth info "no-this-user" does not exist

Expected results:
2. Should not prompt the server doesn't have a resource type "svc"

Additional info:
v3.9.0-0.8.0 doesn't include https://github.com/openshift/origin/pull/17576, while v3.9.0-0.9.0 includes
Thus not sure if it is brought by https://trello.com/c/xe4LrWHd/1095-cli-cli-printers-sanitize-printing-options and https://trello.com/c/jkAVhKgQ/1059-cli-cli-printers-move-printer-handler-registration-to-the-factory,
and seems it is not same as https://bugzilla.redhat.com/show_bug.cgi?id=1515878

Comment 1 Juan Vallejo 2018-01-08 23:19:28 UTC
@David, This is happening because resource shortcuts are not being expanded.
Doing something like `oc get services --user=no-this-user --loglevel=6` does not return an error about the resource not existing.

We seem to have handled a discovery client not existing the same way we do now back in 3.8 [1]. Did the behavior of `legacyscheme.Registry.RESTMapper()` or the resource builder change?

1. https://github.com/openshift/origin/blob/release-3.8/vendor/k8s.io/kubernetes/pkg/kubectl/cmd/util/factory_object_mapping.go#L98

Comment 2 David Eads 2018-01-15 15:01:14 UTC
The entire mapper/typer flow changed in 1.9.  Given that all resources should be discovered, the inability to create a client to look up resources is fatal. I think that https://github.com/kubernetes/kubernetes/pull/58293 makes it so.

Comment 3 Xingxing Xia 2018-01-18 06:00:08 UTC
https://github.com/kubernetes/kubernetes/pull/58293 was just merged a day ago.
Waiting new puddle that will include rebase of it to verify.

Comment 4 Xingxing Xia 2018-01-22 10:21:17 UTC
Still not merged in v3.9.0-0.22.0. Moving to MODIFIED. What's the rebase PR for rebasing the code downstream so that it can be subscribed and tested when rebase is done?

Comment 6 Xingxing Xia 2018-04-13 06:45:51 UTC
Hi Juan, the bug fix will lands in 3.10, right [1]? If yes, please change Target Release and then please Samuel drop from above 3.9 advisory. Currently no latest 3.10 env for verification due to installer bugs, which I'll watch.
[1] Test with latest 3.9 version 3.9.20 (kubernetes v1.9.1+a0ce1bc657) still reproduces bug.

Comment 7 Xingxing Xia 2018-04-16 01:51:34 UTC
Samuel, hi, please help drop this bug from above advisory, thanks

Comment 8 Xingxing Xia 2018-04-17 06:27:41 UTC
Checked in env:
oc v3.10.0-0.21.0
kubernetes v1.10.0+b81c8f8
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://$MASTER_HOST:8443
openshift v3.10.0-0.21.0
kubernetes v1.10.0+b81c8f8

v3.10.0-0.21.0 merged the rebase PR https://github.com/openshift/origin/pull/19137 , tut bug is still reproduced.

BTW, Samuel, bug is still in advisory, please drop

Comment 11 Xingxing Xia 2019-02-27 13:37:52 UTC
Still exist in latest 3.10 oc v3.10.118. Fixed in oc v3.11.86:
3.10.118/oc get svc --user=no-this-user
error: the server doesn't have a resource type "svc"

3.11.86/oc get svc --user=no-this-user
error: auth info "no-this-user" does not exist

Since bug is low, IMO target field can be changed.

Comment 13 errata-xmlrpc 2019-04-11 05:38:22 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:0636


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