when doing provision=false project create/deprovission tasks fail if you are not cluster admin

[itewk]

Currently if you are a non cluster admin user and follow the instructions to change the action for a ProjectRequest to be create that works, but when you follow the instructions to do deprovission by setting provision=false you get an error about not being able to use apply.

There needs to be some way to either set the deprovission action or there needs to be more smarts in the provision=false logic so that if the action: create then the deprovission action will be delete.

[oybed]

This is a "known deficiency" and needs better documentation. In the code, the action is already set to delete instead of create or apply (that's really what the provision flag does). The issue is that a ProjectRequest isn't a "true" object, and it creates a namespace behind the scene. Regular users are limited for what they are allowed to do with namespace objects, and hence this issue. @etsauer and I have had discussions with engineering to improve support for management of namespace as a regular user - including being able to use an object to perform the create/apply/delete actions, but no real solution exists for it as-is.

@etsauer can probably help with additional details here if needed.

There are a couple of things that can be done, short term and long term:

• separate out the project/namespace creation into its own inventory, allowing for everything else to be deleted but the namespace/project (and do this manually afterwards)
• use openshift-applier tags to delete everything bug the projectrequest

Longer term, we could potentially add a "special case" for ProjectRequests in the openshift-applier, but we are really attempting to avoid doing special case handling as the openshift-applier should be just a wrapper that's "lean and (somewhat) dumb".

[oybed]

BTW: @itewk you mentioned "not being able to use apply". Could you please include a capture of that error in this issue?

[oybed]

Also, here's a BZ @etsauer wrote with more info re: ProjectRequests / namespaces and delete: https://bugzilla.redhat.com/show_bug.cgi?id=1537774

[etsauer]

@oybed @itewk there was code in the role that handled a "failed delete" such that applier at least would not fail completely. Might be a regression from all the changes. Either way.. yeah. you can't delete a ProjectRequest, and that becomes a problem for unprivileged users.