Bug 1732932

Summary: Have a method to create openshift-* prefixed projects before product installation
Product: OpenShift Container Platform Reporter: Ryan Hallisey <rhallise>
Component: OLMAssignee: Evan Cordell <ecordell>
OLM sub component: OLM QA Contact: Jian Zhang <jiazha>
Status: CLOSED NEXTRELEASE Docs Contact:
Severity: unspecified    
Priority: unspecified CC: aos-bugs, dmesser, ecordell, igulina, jforrest, jiazha, mbukatov, mfojtik, nmalik, rhallise, shurley
Version: 4.2.0Flags: igulina: needinfo-
Target Milestone: ---   
Target Release: 4.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-20 12:24:06 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 Ryan Hallisey 2019-07-24 18:20:12 UTC
Operators that run on and extend the control plane of OpenShift require an openshift-* prefixed project in order to use OpenShift's Prometheus instance. Since the project is not created by default, the user must create the openshift-* prefixed project, which is blocked by an admission controller. The work around is to create a namespace instead.

It would be a better user experience to have the openshift-* namespaces be created before hand or have some method of creating them during install so the user doesn't have to.  

Error:
[root@cnv-qe-03 ~]# oc whoami
system:admin
[root@cnv-qe-03 ~]# oc new-project openshift-cnv
Error from server (Forbidden): project.project.openshift.io "openshift-cnv" is forbidden: cannot request a project starting with "openshift-"

Workaround in 4.2:
[rhallisey@localhost hco-bundle-registry]$ oc create ns openshift-cnv
namespace/openshift-cnv created
[rhallisey@localhost hco-bundle-registry]$ oc whoami
system:admin

Comment 1 Abhinav Dahiya 2019-07-24 18:22:07 UTC
Why is this an installation time configuration. The admission controller should allow this through some object.

Comment 2 Ryan Hallisey 2019-07-24 18:32:32 UTC
Through what object does the admission controller allow you to create an openshift-* prefixed project?

Comment 3 Jian Zhang 2019-07-25 02:03:55 UTC
The `oc admin` may help.
mac:~ jianzhang$ oc whoami
system:admin
mac:~ jianzhang$ oc adm new-project openshift-cnv
Created project openshift-cnv

Comment 4 Irina Gulina 2019-07-25 07:45:41 UTC
All, also please mind that there is a Web UI case, which has create a Project option only, and no NS. And a CLI case, when a user or (one specific user as comment#3 suggests) can create either a Project or NS. And depends on what resolution this BZ will have, in docs a user may see a mix of CLI and Web UI steps or just one consistent Web UI couple-of-clicks flow.

Comment 5 David Eads 2019-07-25 10:54:02 UTC
There is no admission plugin gating this.  The ProjectRequest endpoint for unprivileged users doesn't allows creating namespaces with that prefix because it is reserved for system level integrations that should have namespace creation powers.

What are you trying to use that requires this namespace?  Who gave permission for an extension to claim an openshift-* namespace?  Why can't the thing you're using create the namespace in question?

I think this bug is in the wrong spot, the openshift-apiserver correctly protects reserved namespaces for ProjectRequests.  Anyone with the power can use a different endpoint.  If you want a better experience for how you create a namespace, I suggest speaking to the operator installing your operator.

Comment 6 Ryan Hallisey 2019-07-25 11:22:36 UTC
> If you want a better experience for how you create a namespace, I suggest speaking to the operator installing your operator
>

That's the target for this bug, but I don't know the component.  This bug is for tracking on how to improve the process for operators that will use an openshift-* prefixed namespace.  Maybe this isn't the place to track?

Comment 7 David Eads 2019-07-25 11:24:50 UTC
I think most new operators are supposed to use OLM and CVO based operators already handle this gracefully, so we'll try OLM.

Comment 8 Ryan Hallisey 2019-07-25 11:30:30 UTC
I didn't see OLM in the list.  Should've been targeted there first, thanks David.

Comment 10 Daniel Messer 2019-08-20 12:23:12 UTC
Closing. Tracked for 4.3 with medium priority as part of the Operator Configurability story. https://jira.coreos.com/browse/PROD-1682