Bug 1313688

Description of problem:
Whenever project is deleted via the CLI, system instantaneously returns a message stating that the project has been deleted.
However, the project has only started being deleted. This will make any scripts that delete/remake projects very unreliable.

Version-Release number of selected component (if applicable):
OSE 3.1.1

How reproducible:
execute twice the next command:
oc new-project trash;oc delete project trash;oc new-project trash

Steps to Reproduce:
1.
2.
3.

Actual results:

root@master # oc new-project trash;oc delete project trash;oc new-project trash
Now using project "trash" on server "https://master.ose3.test:8443".

You can add applications to this project with the 'new-app' command. For example, try:

    $ oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-hello-world.git

to build a new hello-world application in Ruby.
project "trash" deleted
Now using project "trash" on server "https://master.ose3.test:8443".

You can add applications to this project with the 'new-app' command. For example, try:

    $ oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-hello-world.git

to build a new hello-world application in Ruby.

[02/03 09:41:11][~]
root@master # oc new-project trash;oc delete project trash;oc new-project trash
Error from server: project "trash" already exists
project "trash" deleted
Error from server: project "trash" already exists

[02/03 09:41:26][~]
root@master # 


Expected results:


Additional info:

API calls are not designed to be long running. Processes that need to wait until project cleanup is complete can watch or poll until the project no longer is in the Terminating state and is deleted.

All deletion is potentially asynchronous (for example, by default, pod deletion waits for nodes to send kill signals to pod processes and for them to exit gracefully)

(In reply to Jordan Liggitt from comment #4)
> All deletion is potentially asynchronous (for example, by default, pod
> deletion waits for nodes to send kill signals to pod processes and for them
> to exit gracefully)

Or can we delete the kubernetes related resources firstly?

I saw we first delete our openshift resources(policy bindings), and this will make project invisible for users to let user think the project have already been deleted, maybe the project will be deleted after several seconds actually.

We have report a bug about this https://bugzilla.redhat.com/show_bug.cgi?id=1324465, but the solution still can not make user create the same name project after the project is invisible.

Deletion order should not be counted on. Multiple workers can be spawned to delete resources in parallel.