Feature Overview (aka. Goal Summary)  

Provide a declarative way to create OpenShift "project"s according to the projectRequestTemplate. Projects, in contrast to namespaces, are provisioned based on a project template defined by cluster admins. The flow for project creation is currently not compatible with GitOps workflows and customers are forced to skip this capability and fallback on creating namespaces. 

Goals (aka. expected user outcomes)

Enable customers to create OpenShift projects based on a project template using Argo CD

Requirements (aka. Acceptance Criteria):

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

Background

If self-provisioner users want to create an OpenShift project, they have to do it via the command line. It is not possible to do it via GitOps workflows and Argo CD.

The reason of that is because the command oc new-project does not create a Project object directly. Instead, it creates a ProjectRequest. The latter is a temporary object which is deleted once the Project creation is approved and carried out.

If a ProjectRequest is tried to be synchronized via Argo CD; it will be marked as out of sync later because, as mentioned previously, that object is temporary.

If a cluster-admin provides create Project permissions to the user (self-provisioner role by default only includes create ProjectRequest); then the Project object will be able to be synchronized, but not the objects inside it. The reason is because users who create Projects directly bypassing ProjectRequest do not get any kind of permissions inside the project created. Therefore it is useless unless users also get create rolebindings.authorization.openshift.io permission, which would extend their privileges too much in my opinion.

Customer Considerations

Customers employ different workarounds around this issue with the many disabling the project template capability of OpenShift and fall back on creating a namespace and relevant objects entirely through the GitOps workflow. 

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

<your text here>

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>