Bug 1405636 - oc status fails with "cannot get projects in project" error when there are no projects
Summary: oc status fails with "cannot get projects in project" error when there are no...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.3.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Juan Vallejo
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-16 22:06 UTC by Scott M Stark
Modified: 2017-07-24 14:11 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: `oc status` tries to generate a status for the "default" cluster namespace if a user has not yet created a project after logging in. Consequence: The user would see a forbidden status error "cannot get projects in project" when their context was still in the cluster's "default" namespace after logging in, and did not have permissions to "LIST" in this namespace. Fix: `oc status` now checks to see if a user cannot list projects in the default namespace. Result: The user no longer sees the error message "cannot get projects in project <default cluster namespace>" when they execute `oc status` and have no projects in their current namespace. They instead see a message prompting them to create a new project, or to contact their administrator to have one created for them.
Clone Of:
Environment:
Last Closed: 2017-04-12 19:07:53 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


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

Description Scott M Stark 2016-12-16 22:06:10 UTC
Description of problem:
I'm working with the api.dev-preview-stg.openshift.com OSO interface, and if I just do a login and then immediately do an 'oc status', I get an error message instead of a normal return indicating there are no projects.

[demo 623]$ oc status
Error from server: User "starksm64" cannot get projects in project "default"

Version-Release number of selected component (if applicable):
v3.4.0.28+dfe3a66 (online version 3.4.0.6)

How reproducible:
Always

Steps to Reproduce:
1. login to http://mandrillapp.com/track/click/30918608/console.dev-preview-stg.openshift.com using github account.
2. Run oc login https://api.dev-preview-stg.openshift.com --token=...
3. Run oc status

Actual results:
[demo 623]$ oc status
Error from server: User "starksm64" cannot get projects in project "default"

Expected results:
A non-error result that simply says there are no projects in "default"

Additional info:

Comment 1 Juan Vallejo 2016-12-19 19:47:34 UTC
Related PR: https://github.com/openshift/origin/pull/12304

Comment 2 Xingxing Xia 2016-12-22 10:13:48 UTC
Checked on:
$ oc version
oc v1.5.0-alpha.0+8a850ad-503
kubernetes v1.4.0+776c994
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://localhost:8443
openshift v1.5.0-alpha.0+8a850ad-503
kubernetes v1.4.0+776c994

Now, if user has no project and oc login, then oc status, it outputs:
You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

This result fixes the bug.


In the 1st comment of PR https://github.com/openshift/origin/pull/12304, it mentions:
if a user does not have access to request new projects, the following message
is printed instead.

This mention is also checked. It works. See below.
1. Make a user not have access to request new projects, using steps in https://bugzilla.redhat.com/show_bug.cgi?id=1262696#c2 or https://bugzilla.redhat.com/show_bug.cgi?id=1262696#c9

2. Then oc login

3. Then oc status. Now it outputs below expected message instead:
You don't have any projects. Contact your system administrator to request a project

Comment 3 Xingxing Xia 2016-12-22 10:15:27 UTC
However, try following test, the message is incorrect

$ oc new-project xxia-proj
$ oc new-project xxia-proj-2nd

Incorrect "You don't have any projects" here.
$ oc status -n default
You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

$ oc delete project xxia-proj-2nd

And incorrect here, because I have xxia-proj
$ oc status
You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

Comment 4 Juan Vallejo 2016-12-22 19:03:50 UTC
(In reply to Xingxing Xia from comment #3)
> However, try following test, the message is incorrect
> 
> $ oc new-project xxia-proj
> $ oc new-project xxia-proj-2nd
> 
> Incorrect "You don't have any projects" here.
> $ oc status -n default
> You don't have any projects. You can try to create a new project, by running
> 
>     oc new-project <projectname>
> 
> $ oc delete project xxia-proj-2nd
> 
> And incorrect here, because I have xxia-proj
> $ oc status
> You don't have any projects. You can try to create a new project, by running
> 
>     oc new-project <projectname>

Thanks for catching this. I have opened a PR here (https://github.com/openshift/origin/pull/12328) to address these cases.

Comment 5 XiaochuanWang 2017-01-26 02:52:59 UTC
Both oc v3.3.1.11 and v3.4.1.2 reproduced, but v3.5.0.8+736adae does not reproduce.

# oc get project
NAME      DISPLAY NAME   STATUS
test                     Active

# oc delete project test
project "test" deleted

# oc status
Error from server: User "xiaocwan" cannot get projects in project "test"


(oc v3.5.0.8+736adae) # oc status
You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>


Does it need to back port to 3.3 and 3.4?

Comment 6 Juan Vallejo 2017-01-27 14:30:20 UTC
No, I do not believe we are backporting this. Due to one of the tests for the original PR having a race condition, it has been reverted.
A new PR with fixed tests has been opened here: https://github.com/openshift/origin/pull/12668, will change this bug to ON_QA once PR is merged

Comment 7 Fabiano Franz 2017-01-27 16:59:35 UTC
No backport here.

Comment 8 Juan Vallejo 2017-01-31 18:35:55 UTC
PR https://github.com/openshift/origin/pull/12668 merged. Moving to ON_QA

Comment 9 Yadan Pei 2017-02-03 04:00:30 UTC
Checked against 
oc v3.5.0.14+20b49d0
kubernetes v1.5.2+43a9be4


1. User has no projects -> Then 'oc login' -> Then 'oc status'
$ oc login <server> --token=<token>
$ oc status
You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

2. User does not have access to request new projects -> Then 'oc login' -> Then 'oc status'
# oadm policy remove-cluster-role-from-group self-provisioner system:authenticated
# oadm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth
$ oc login <server>
$ oc status
You don't have any projects. Contact your system administrator to request a project.

3. Run 'oc status' in multiple scenarios
$ oc new-project yapei-1
$ oc new-project yapei-2

== Run 'oc status' to check 'default' project status 
$ oc status -n default
Error from server (Forbidden): User "yapei" cannot get project "default"

== Run 'oc status' to check one of users' project status
$ oc status -n yapei-1
In project yapei-1 on server <server>

You have no services, deployment configs, or build configs.
Run 'oc new-app' to create an application.

== Delete current project 'yapei-2' and run 'oc status' without parameter
$ oc delete project yapei-2
project "yapei-2" deleted
$ oc status
Error from server (Forbidden): User "yapei" cannot get project "yapei-2"

Move to VERIFIED since no backport here

Comment 11 errata-xmlrpc 2017-04-12 19:07:53 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.