Bug 1393289 - In some error, `oc get` should remove the message No resources found
Summary: In some error, `oc get` should remove the message No resources found
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.4.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Juan Vallejo
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks: 1612628
TreeView+ depends on / blocked
 
Reported: 2016-11-09 09:32 UTC by Xingxing Xia
Modified: 2018-08-06 03:01 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: `oc get` would return the message "No resources found", even in the case of a request or server error. Consequence: The user would see the message "No resources found" even in cases where resources did exist, but could not be retrieved due to a connection error. Fix: The command `oc get` was updated to only show the message "No resources found" in cases when resources truly did not exist in the server. Result: `oc get` no longer displays "No resources found" in cases when there is an error retrieving resources from the server.
Clone Of:
: 1612628 (view as bug list)
Environment:
Last Closed: 2017-04-12 19:16:27 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0884 normal SHIPPED_LIVE Red Hat OpenShift Container Platform 3.5 RPM Release Advisory 2017-04-12 22:50:07 UTC

Description Xingxing Xia 2016-11-09 09:32:14 UTC
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:

Comment 1 Juan Vallejo 2016-11-10 20:56:52 UTC
Relaated PR: https://github.com/openshift/origin/pull/11878

Comment 2 Juan Vallejo 2016-11-14 16:29:50 UTC
This has been fixed upstream in this PR https://github.com/kubernetes/kubernetes/pull/35115

Will obtain fix with next kubernetes rebase

Comment 3 Xingxing Xia 2016-11-15 05:30:28 UTC
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"

Comment 4 Xingxing Xia 2016-11-17 09:16:22 UTC
The fix is not within latest AMI devenv-rhel7_5373. Not sure when is next rebase. Moving to MODIFIED ... :)

Comment 5 XiaochuanWang 2016-11-18 09:02:44 UTC
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')

Comment 7 Xingxing Xia 2016-11-21 01:41:05 UTC
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!

Comment 8 Xingxing Xia 2016-11-25 08:18:22 UTC
(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...

Comment 11 Yanping Zhang 2017-01-13 10:19:19 UTC
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.

Comment 12 Juan Vallejo 2017-01-13 15:44:54 UTC
> 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

Comment 13 Yanping Zhang 2017-01-16 02:13:55 UTC
According to Comment 11 and Comment 12, there is no other issue found now, the bug have been fixed, so move it to Verified.

Comment 15 errata-xmlrpc 2017-04-12 19:16:27 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-2017:0884


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