cluster-api: [0.1] Deleting Cluster does not delete
/kind bug
What steps did you take and what happened:
- Create a cluster in the cluster API
- Add a Machine or MachineDeployment
- Wait for all objects to become available
kubectl deletethe cluster- The cluster gets a deleted-at, but nothing else gets deleted
What did you expect to happen:
The Machines, then MachineDeployments should be marked to be deleted, then the cluster deleted once their resources have been completely removed
Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]
Environment:
- Cluster-api version: master
- Minikube/KIND version: 0.1.0-alpha
- Kubernetes version: (use
kubectl version): 1.13 - OS (e.g. from
/etc/os-release): Ubuntu Bionic
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 27 (23 by maintainers)
I talked with @ncdc about this in #cluster-api slack yesterday (thanks for answering all my questions!), and I wanted to add a summary of that here:
For a cascading delete, the apiserver decides which strategy to use by looking for the strategy finalizer (e.g.
foregroundDeletion) on the parent object. The client can override the strategy; kubectl always selects the background strategy. When the background strategy is chosen, theforegroundDeletionfinalizer is removed from the parent object, and if no other finalizers exist, the parent object is immediately deleted.As a kubectl user, it seems like the important question is “Am I willing to wait for cascading deletes?” If Yes, then use foreground strategy. Otherwise, use background strategy. This is not a question kubectl asks today. Note that the “Am I willing to wait for deletes?” question is already asked by the
--waitflag.However, the choice of strategy impacts correctness of the deletes for CAPA. If you use the background strategy to delete the cluster, the delete will never succeed because of AWS dependency issues that require machine objects to be deleted prior to the cluster object.
If the wrong choice can lead to incorrect behavior, the user experience will be terrible. So either CAPA needs to work around upstream cascading delete behavior (see the comment just above), or that behavior needs to change.
@ncdc I’m partial to say yes the
Clusterand other parent objects should stick around until their child resources/objects are cleaned up.Like I said above, finalizers and controller managed deletion would do it, analagous to namespace finalizer.
@AlainRoy the machines are deleted before the machinesets, but the machinesets are marked as being deleted (by the deletedAt timestamp). This way they know not to create new deployments.