Handle Bundle deletion

[ash2k]

Smith hopefully will be relying on Kubernetes' Garbage Collector (GC) + finalizers to handle deletion of resources in case of Bundle deletion. At the moment GC does not support TPRs (Bundle is a TPR) and has other various issues unfortunately:

• Garbage collector should support non-core APIs kubernetes/kubernetes#44507
• Panic and crash after using TPRs kubernetes/kubernetes#43430
• federation: Support cascading deletion kubernetes/kubernetes#33612

Finalizers do not work for TPRs:

• Finalizers do nothing for TPR instances kubernetes/kubernetes#40715

Once GC and finalizers are suitable for this use case we should add a finalizer to each Bundle to make sure all resources provisioned by a Bundle are deleted before Smith removes the finalizer from it to let GC delete the Bundle object.
Actually, we don't need finalizers for the Bundle - it will be added and removed by GC itself. We just need GC to handle references properly.

[nilebox]

At the moment GC does not support TPRs

Just out of curiousity: what about Kubernetes API server (the framework to create own Kubernetes-style servers, such as Service Catalog)? Does it provide GC out of the box, or do you have to manually copy code from Kubernetes core and implement it yourself?

Also, wonder if it's possible to implement TPR finalizers ourself and raise a PR to Kubernetes.

[ash2k]

@nilebox I don't know for sure, but presumably GC is a component of the main api server and it should work with all other api servers (and across them) i.e. you don't need to copy it into your server. However, I haven't tested it and I'm 99% confident it does not work yet because api aggregation is not available yet.

I think it is a good idea to look at implementing finalizers ourselves and PRing it.

p.s. I also thought about implementing our own api server for Bundle type to workaround all the TPR limitations but I really hope we will not have to.

[ash2k]

GC and finalizers work for CRs in Kubernetes 1.8+.