Problem Statement
When a BootcNodePool is deleted, its member BootcNode objects are deleted, and the bootc.dev/managed label is removed from the underlying nodes. While deleting an idle BootcNodePool is straightforward, ambiguity arises when a pool is deleted while an OS update rollout is in progress. Because OS updates managed by bootc-operator involve multi-stage operations (image staging, cordoning, draining, reboots, and post-reboot health verification), deleting a pool mid-rollout would currently leave the cluster in an inconsistent state.
Proposal
When a BootcNodePool deletion is triggered during an active rollout, the operator must determine whether to push remaining nodes forward or halt new update triggers. This decision should depend on the percentage of nodes that have completed the update. If, for example, less than 50% of the nodes have received the update, they should roll them back to the old OS version. By comparison, if over 50% of the nodes have received the update, then the update should continue forward. Ideally, this threshold should be a user-configurable value on each BootcNodePool, with a default value of 50%.
Once the rollback or update is complete, then the operator can remove any finalizers from the BootcNode and BootcNodePool objects, allowing their deletion to be processed. Because this process can take a while on a large / loaded cluster, .status.conditions updates help to inform the cluster admin (and other processes) that the operator / cluster is not in a hung state.
Problem Statement
When a
BootcNodePoolis deleted, its memberBootcNodeobjects are deleted, and thebootc.dev/managedlabel is removed from the underlying nodes. While deleting an idleBootcNodePoolis straightforward, ambiguity arises when a pool is deleted while an OS update rollout is in progress. Because OS updates managed by bootc-operator involve multi-stage operations (image staging, cordoning, draining, reboots, and post-reboot health verification), deleting a pool mid-rollout would currently leave the cluster in an inconsistent state.Proposal
When a
BootcNodePooldeletion is triggered during an active rollout, the operator must determine whether to push remaining nodes forward or halt new update triggers. This decision should depend on the percentage of nodes that have completed the update. If, for example, less than 50% of the nodes have received the update, they should roll them back to the old OS version. By comparison, if over 50% of the nodes have received the update, then the update should continue forward. Ideally, this threshold should be a user-configurable value on eachBootcNodePool, with a default value of 50%.Once the rollback or update is complete, then the operator can remove any finalizers from the
BootcNodeandBootcNodePoolobjects, allowing their deletion to be processed. Because this process can take a while on a large / loaded cluster,.status.conditionsupdates help to inform the cluster admin (and other processes) that the operator / cluster is not in a hung state.