Currently MCM providers implement GetMachineStatus such that it returns whether VM backing the machine object is present or not. It doesn't say anything about the other resources like disks , nics.
There could be unexpected scenarios , where VM couldn't be created while disks and nics get created (leftovers). In such scenario CreateMachine should delete these leftover nics and disks before going for another retry of creation.
Because if it goes for creation directly , then it can happen that the cloudprovider might deny creation of VM, due to some constraints with attaching already existing resources to the VM.
Currently the providers are dealing with this scenario using orphan collection when creationTimeout happens, because DeleteMachine would also not delete these resources as it depends on GetMachineStatus, which is not ideal and risky.
Why is this needed:
To improve dealing with leftovers and mitigate errors in machine creation
himanshu-kun
commented
1 year ago
How to categorize this issue?
/area robustness /kind enhancement /priority 3
What would you like to be added:
Currently MCM providers implement
GetMachineStatussuch that it returns whether VM backing the machine object is present or not. It doesn't say anything about the other resources like disks , nics.There could be unexpected scenarios , where VM couldn't be created while disks and nics get created (leftovers). In such scenario
CreateMachineshould delete these leftover nics and disks before going for another retry of creation. Because if it goes for creation directly , then it can happen that the cloudprovider might deny creation of VM, due to some constraints with attaching already existing resources to the VM.Currently the providers are dealing with this scenario using orphan collection when creationTimeout happens, because
DeleteMachinewould also not delete these resources as it depends onGetMachineStatus, which is not ideal and risky.Why is this needed:
To improve dealing with leftovers and mitigate errors in machine creation