Red Hat Bugzilla – Bug 1393289
In some error, `oc get` should remove the message No resources found
Last modified: 2018-08-05 23:01:06 EDT
Description of problem: Without permission to list resource, `oc get` should remove the message No resources found Version-Release number of selected component (if applicable): openshift v3.4.0.23+24b1a58 How reproducible: Always Steps to Reproduce: With normal user, check: 1. $ oc get users 2. more info: $ oc get users --loglevel 6 3. Actual results: 1. Get: No resources found. Error from server: User "xxia@redhat.com" cannot list all users in the cluster 2. Get: ... GET https://<master>:443/oapi/v1/users 403 Forbidden in 320 milliseconds No resources found. ... "message": "User \"xxia@redhat.com\" cannot list all users in the cluster", "reason": "Forbidden", "details": { "kind": "users" }, "code": 403 }] ... Error from server: User "xxia@redhat.com" cannot list all users in the cluster Expected results: Steps 1 and 2, 'Error from server: User "xxia@redhat.com" cannot list all users in the cluster' is enough. Should remove No resources found Additional info:
Relaated PR: https://github.com/openshift/origin/pull/11878
This has been fixed upstream in this PR https://github.com/kubernetes/kubernetes/pull/35115 Will obtain fix with next kubernetes rebase
Waiting for that rebase ... PS: That rebase should also fix following case when user has no perm to view other project $ oc get pod -n default No resources found. Error from server: User "xxia" cannot list pods in project "default"
The fix is not within latest AMI devenv-rhel7_5373. Not sure when is next rebase. Moving to MODIFIED ... :)
Tested on oc v3.4.0.27 Following resources reproduced as well: componentstatuses (aka 'cs') imagestreamimages (aka 'isimage') ingress (aka 'ing') groups nodes (aka 'no') namespaces (aka 'ns') persistentvolumes (aka 'pv')
Upstream PR 35115 is still not yet rebased in. Checked as follows, on today's latest AMI devenv-rhel7_5391: $ openshift version openshift v1.5.0-alpha.0+3b2bbe5 kubernetes v1.4.0+776c994 <-- Get this version etcd 3.1.0-rc.0 $ cd ~/github.com/openshift/kubernetes; git pull $ git log --pretty="%h %cd - %s" --date=local 776c994 | grep '35115' Output from `git log ...` is empty, meaning the PR is not rebased in. Hi, QE has not idea of the rebase schedule. Could you predict when the rebase is done into openshift and give a notification here after rebase then? That helps much. Thanks!
(In reply to Xingxing Xia from comment #3) > That rebase should also fix following case ... Found another error case the fix should also fix. The case does not concern perm. $ oc get pod --request-timeout=1ms No resources found. Unable to connect to the server: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) $ echo $? 1 -------- FYI, as comparsion, following error case works, though. It does NOT include No resources found: $ oc get pod --unknown-flag Error: unknown flag: --unknown-flag ...skip...
Upstream fix is now in Origin [1][2] Moving to ON_QA [1] https://github.com/openshift/origin/blob/master/vendor/k8s.io/kubernetes/pkg/kubectl/cmd/get.go#L321 [2] https://github.com/openshift/origin/blob/master/vendor/k8s.io/kubernetes/pkg/kubectl/cmd/get.go#L399
Origin version: oc v1.5.0-alpha.1+030a95b-217 OCP version: oc v3.5.0.3+f0c7a0e Checked on origin and OCP 3.5, the issues pointed out in description and comments are all fixed. There is another confusion when run: $ oc get project No resources found. The output info is not clear, it's better to show info like this:"No projects found for user *** " Assign the bug back first, if dev thinks it's not an issue, pls move ON_QA again, then QE will verify it.
> The output info is not clear, it's better to show info like this:"No projects found for user *** " > Assign the bug back first, if dev thinks it's not an issue, pls move ON_QA again, then QE will verify it. As far as I understand, projects are considered a "resource". I do not agree with making a special case just for a single resource type. Moving back to ON_QA
According to Comment 11 and Comment 12, there is no other issue found now, the bug have been fixed, so move it to Verified.
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-2017:0884