During upgrades from 17.0.1 to latest azure operator master, the node pools's backing VMSSes were deleted and recreated.
There were a few reasons for that
after being copied to the new apiVersions, the machinePool and azureMachinePool CRs were deleted. Despite the fact the finalizers were removed, it could happen that the controller did one last reconciliation loop for the deletion event. Solved by adding the pause annotations just before deleting the CR.
the ownerReference on the azureMachinePool CR were correctly updated to point to the new machinePool apiVersion, but the uid of the machinepool was still the old one. This meant when the old machinePool (the experimental one) was deleted by azure-operator, controller-manager thought the new azuremachinepool was orphaned, and garbage collected it. Fixed by adjusting the UID during creation of non-exp CRs.
During upgrades from 17.0.1 to latest azure operator master, the node pools's backing VMSSes were deleted and recreated. There were a few reasons for that
machinePoolandazureMachinePoolCRs were deleted. Despite the fact the finalizers were removed, it could happen that the controller did one last reconciliation loop for the deletion event. Solved by adding the pause annotations just before deleting the CR.azureMachinePoolCR were correctly updated to point to the new machinePool apiVersion, but the uid of the machinepool was still the old one. This meant when the old machinePool (the experimental one) was deleted by azure-operator,controller-managerthought the new azuremachinepool was orphaned, and garbage collected it. Fixed by adjusting the UID during creation of non-exp CRs.