Delete cluster operations always seem to hang

[j-griffith]

What steps did you take and what happened:
Created a basic 3 node cluster using CAPP, did a few things and then tried to delete the cluster using both "kubectl delete -f cluster.yml" and "kubectle delete cluster "

The result is the Cluster object hangs on "Deleting" seemingly indefinitely. I'm assuming this is probably an issue with a finalizer somewhere but haven't managed to track it down.

What did you expect to happen:
I expected this would delete the cluster and clean up the resources I provisioned within Equinix.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-packet version:

• Kubernetes version: (use kubectl version): Management cluster is a kind cluster (GitVersion:"v1.22.1") and the deployed cluster is also 1.22.1 running on Ubuntu 20.04

• OS (e.g. from /etc/os-release):

[detiber]

I would expect either approach to deletion to work, though I would highly recommend kubectl delete cluster over kubectl delete -f cluster.yml to let the cluster deletion happen in the safest order.

There should be some info available in the controller logs related to what is holding up the deletion.

[j-griffith]

@detiber I'll spin up a fresh deploy adn check the logs when I get a chance and post here, thanks for the response

[j-griffith]

Well, I've tried a few things to reproduce this without any luck. What I suspect is (based on some logs I still had) is that something was still provisioning when I attempted to delete. Sorry I don't have good info here, I'll close this and if I manage to see it again I'll pull the manager logs and see what's up.

[detiber]

@j-griffith I do have a fix in place for fixing a deletion issue when a device fails to provision in #269, so it is possible you hit that issue.

[j-griffith]

@j-griffith I do have a fix in place for fixing a deletion issue when a device fails to provision in #269, so it is possible you hit that issue.

Awesome, thanks for pointing me to that. I'm pretty confident it was an issue with provisioning that I didn't catch initially; I haven't had any trouble since.