The controller departs from the usual scheme of adding a finalizer, and exiting early, at the top of the Reconcile func. This PR documents why, and adds some early exits where possible.
In addition: the code that handles finalization (cleaning up when a Stack has been deleted) removes the finalizer record, saves the object, then waits for the Kubernetes API server to delete the object. The rationale is that waiting until the cache has caught up means the reconciler "knows" it has been deleted. Waiting for the deletion to be seen by the client is not necessary, though -- even if the controller sees the object again, once the finalizer has been removed it will exit without processing it.
The controller departs from the usual scheme of adding a finalizer, and exiting early, at the top of the Reconcile func. This PR documents why, and adds some early exits where possible.
In addition: the code that handles finalization (cleaning up when a Stack has been deleted) removes the finalizer record, saves the object, then waits for the Kubernetes API server to delete the object. The rationale is that waiting until the cache has caught up means the reconciler "knows" it has been deleted. Waiting for the deletion to be seen by the client is not necessary, though -- even if the controller sees the object again, once the finalizer has been removed it will exit without processing it.