Bug 1529482
| Summary: | "factory_object_mapping.go ... Unable to get a discovery client to find server resources" when prompting "the server doesn't have a resource type" | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Xingxing Xia <xxia> |
| Component: | oc | Assignee: | Maciej Szulik <maszulik> |
| Status: | CLOSED ERRATA | QA Contact: | Xingxing Xia <xxia> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.9.0 | CC: | aos-bugs, deads, jokerman, mmccomas, smunilla |
| Target Milestone: | --- | Keywords: | Rebase, Regression, UpcomingRelease |
| Target Release: | 3.11.z | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-04-11 05:38:22 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-12-28 10:31:57 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 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. https://github.com/kubernetes/kubernetes/pull/58293 was just merged a day ago. Waiting new puddle that will include rebase of it to verify. 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? 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. Samuel, hi, please help drop this bug from above advisory, thanks 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 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. 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 |