Project deletion

[0xmichalis]

Currently the only way to delete a project is via oc delete project <project_name>. By using delete, users can even delete the project they currently are in:

[vagrant@openshiftdev sample-app]$ oc project
Using project "test" from context named "test/localhost:8443/test" on server "https://localhost:8443".
[vagrant@openshiftdev sample-app]$ oc delete project test
project "test" deleted
[vagrant@openshiftdev sample-app]$ oc project
error: you do not have rights to view project "test".

This doesn't feel right. How about providing a -D flag on oc project that will take care of that and won't allow for a project deletion if the user is currently using it (similar to what git branch -D is doing) ?

cc: @fabianofranz @deads2k @derekwaynecarr

[liggitt]

I think the API should support it, though whether a project admin should have permission to delete their own project is open for debate (they typically can't directly create a project, and have very limited ability to update it)

[deads2k]

If a user explicitly asks to delete a resource that they have rights to delete, I'm not sure that I'd want to stop them from doing it. It's difficult to say that a user accidentally typed "project/their entire project name" after a delete.

[derekwaynecarr]

It does seem pro-user to do something better here.

Is there a reason why we can't special case delete of a namespace/project
to at least ensure the current context is stripped of the named project?

Seems like if config is scoping on a resource, we should be able to hook
against that resource post deletion.

On Thursday, August 13, 2015, David Eads <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

If a user explicitly asks to delete a resource that they have rights to
delete, I'm not sure that I'd want to stop them from doing it. It's
difficult to say that a user accidentally typed "project/their entire
project name" after a delete.

—
Reply to this email directly or view it on GitHub
#4141 (comment).

[deads2k]

There is no guarantee that the current project actually is the current context in a kubeconfig file (-n foo). I don't know that there is a reasonable expectation that a kubectl delete operation would mutate a ~/.kube/config call. Do you want to propose it upstream or were you thinking of special casing this in openshift?

[liggitt]

ensure the current context is stripped of the named project

that feels weird... if I delete my current project, and we strip the current context of the namespace, then it defaults to "default". Which is weirder, being told I don't have access to the project I just deleted, or being told I don't have access to "default"?

[fabianofranz]

Similar: https://bugzilla.redhat.com/show_bug.cgi?id=1253194

[derekwaynecarr]

I am not sure I have the best answer, but I can sympathize with the user in
this situation.

If it's a matter of providing a better solution, then I like the original
suggestion from Michail, and training users to use that method to do the
action.

On Thu, Aug 13, 2015 at 3:07 PM, Fabiano Franz notifications@github.com
wrote:

Similar: https://bugzilla.redhat.com/show_bug.cgi?id=1253194

—
Reply to this email directly or view it on GitHub
#4141 (comment).

[liggitt]

I really don't want to start special-casing things in oc delete if the API supports the operation

[derekwaynecarr]

I am not saying to remove support for

oc delete project foo

That is actually really good for scripting.

I am saying to promote a more user friendly method for the average end
user.

oc project -D foo

Which would do all the appropriate fixups.

On Thursday, August 13, 2015, Jordan Liggitt notifications@github.com
wrote:

I really don't want to start special-casing things in oc delete if the
API supports the operation

—
Reply to this email directly or view it on GitHub
#4141 (comment).

[smarterclayton]

It seems unlikely a user is going to find oc project -D foo ever.

[soltysh]

The only thing I can think of would be to warn a user about that particular removal, which could be bypassed by passing -f flag, similarly to what rm does on linux. The problem is that we'd have to modify the delete command so this behavior works for some resources and for some don't which sounds nasty 😁

[deads2k]

The only thing I can think of would be to warn a user about that particular removal, which could be bypassed by passing -f flag, similarly to what rm does on linux. The problem is that we'd have to modify the delete command so this behavior works for some resources and for some don't which sounds nasty

I'm actually ok with the concept of marginally "protected" resources. Not all resources are equal. It actually seems reasonable to me require an --i-really-mean-to-do-this-flag for limitrange, namespace, project, policy, policybinding, node (maybe), and some kinds of persistentvolumeclaims (accidental recycling is a bitch), serviceaccount (when in use by an rc). Basically when its impossible to recover the object you're deleting (persistent volumes), when you'll break other infrastructure (serviceaccounts), when you'll make your system inaccessible (authorization objects), or you'll have massive ripples (namespaces).

[soltysh]

That was my intention, since we provide users with a client implementation we could be pro-active warning users about the risk he not necessarily might be aware of.

[smarterclayton]

We could require "--confirm" on deletion of resources of a certain name.
It would be a breaking API change though, which is a concern. Needs to be
discussed and proposed upstream.

On Fri, Aug 14, 2015 at 8:56 AM, Maciej Szulik notifications@github.com
wrote:

That was my intention, since we provide users with a client implementation
we could be pro-active warning users about the risk he not necessarily
might be aware of.

—
Reply to this email directly or view it on GitHub
#4141 (comment).

Clayton Coleman | Lead Engineer, OpenShift