odo delete should wait until all component related resources are gone before exit

[dgolovin]

/kind bug

What versions of software are you using?

Operating System:
Windows 10 Pro
Output of odo version:
odo v1.1.0 (86c7e2c9)

How did you run odo exactly?

Deleting component while in context folder with
odo delete

Then pushing component to cluster right away
odo push

Actual behavior

odo push fails with:

c:\Temp\nodejs-ex>"c:\p\vscode-openshift-tools\out\tools\win32\odo.exe" push -v 4
I0304 22:15:10.393157   14816 common_push.go:117] SourceLocation: ./
I0304 22:15:10.394157   14816 common_push.go:125] Source Path: c:\Temp\nodejs-ex
Validation
 -  Checking component  ...
I0304 22:15:10.443158   14816 occlient.go:2549] Getting DeploymentConfig: nodejs-ex-app1
I0304 22:15:10.466161   14816 component.go:506] Checking source location: ./
 V  Checking component [26ms]

Configuration changes
 V  Initializing component
 -  Creating component  ...
I0304 22:15:10.485159   14816 occlient.go:747] Found exact image tag match for nodejs:8
 X  Creating component [88ms]
 X  Failed to create component with name nodejs-ex. Please use `odo config view` to view settings used to create component. Error: failed to create component with args {Name:nodejs-ex SourcePath:./ SourceRef: SourceType:local ImageName:nodejs:8 EnvVars:[DEBUG_PORT=5858] Ports:[8080/TCP 5858/TCP]  Resources:&ResourceRequirements{Limits:ResourceList{},Requests:ResourceList{},} ApplicationName:app1 Wait:false StorageToBeMounted:map[] StdOut:<nil>}: unable to create PVC for nodejs-ex-app1: unable to create PVC: object is being deleted: persistentvolumeclaims "nodejs-ex-app1-s2idata" already exists

Expected behavior

odo delete exits when all components resources are gone.
odo push works as usual and deploys component.

Any logs, error output, etc?

see Actual behavior.

[adisky]

We are adding ownerReference of DeploymentConfig to the s2idata PVC https://github.com/openshift/odo/blob/master/pkg/occlient/occlient.go#L3067
So when user requests to delete a component, DeploymentConfig gets deleted immediately, and s2idata PVC is deleted by Kubernetes Garbage Collector, so there is little delay in deletion of PVC.

We can control the behavior of GarbageCollector in the DeploymentConfig Delete requests, https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#controlling-how-the-garbage-collector-deletes-dependents, specifying it to foreground-cascading-deletion which deletes the dependents first and then delete the owner object. It would delete the PVC immediately.