Deletion of Machine+associated VM/Node should not hang if corresponding MachineClass is not found

[elankath]

How to categorize this issue?

/area robustness
/kind bug
/priority 3

What happened:

)This happened during repetition of local gardener dev setup) A dangling Machine object was found, associated with a MachineClass that did not exist. Neither the Machine nor its Node (or associated VM) was deleted by MCM and the Machine was stuck in the Terminating phase and kept being re-added to the termination queue.

E1217 10:52:25.202638       1 machine_util.go:87] MachineClass shoot--local--i034796l-bc/shoot--local--i034796l-bc-bc-z1-2dab0 not found. Skipping. machineclass.machine.sapcloud.io "shoot--local--i034796l-bc-bc-z1-2dab0" not found

E1217 10:52:25.202646       1 machine.go:277] cannot reconcile machine "shoot--local--i034796l-bc-bc-z1-5dd4d-tvp4n": machineclass.machine.sapcloud.io "shoot--local--i034796l-bc-bc-z1-2dab0" not found

I1217 10:52:25.202655       1 machine.go:133] Adding machine object to termination queue "shoot--local--i034796l-bc/shoot--local--i034796l-bc-bc-z1-5dd4d-tvp4n" after 10

What you expected to happen:
Machine object and associated resources should be deleted even if its corresponding MachineClass is not found.

How to reproduce it (as minimally and precisely as possible):

• (original reproduction difficult as it involved repeated attempts at gardener local dev setup of an erreneous local seed_shoot.)
• simpler reproduction can be done by simply removing finalizers of a MachineClass, deleting the MachineClass and then deleting corresponding Machine(s).
• The Machine(s) associated with the MachineClass will remain stuck in Terminating phase and neither Node object nor associated VM are deleted.

Anything else we need to know?:
NO

Environment:
ALL

• Kubernetes version (use kubectl version): any
• Cloud provider or hardware configuration: any
• Others:

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 60d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 60d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as active with /lifecycle active
• Mark this issue as frozen with /lifecycle frozen
• Mark this issue as fresh with /remove-lifecycle stale
• Mark this issue as rotten with /lifecycle rotten
• Close this issue with /close

/lifecycle stale