On k8s, for a rollback case, the leader unit will have the recovery state, rendering the cluster_state with the recovery value.
This will defer the on_upgrade_changed handler indefinitely because of this test.
The defer makes sense for VM cases, where on charm refresh, all units will set it state to ready on the upgrade-charm handler.
On K8s, only the upgrading unit will receive the upgrade-charm event, and if the leader unit is not the upgrading unit, the cluster_state will remain in the recovery state.
Deferring the on_upgrade_changed indefinitely will prevent the upgrade_stack being popped, and a subsequent resume-upgrade will set the wrong partition value, staling the rollback process.
github-actions[bot]
commented
10 months ago
On k8s, for a rollback case, the leader unit will have the
recoverystate, rendering thecluster_statewith therecoveryvalue.This will defer the
on_upgrade_changedhandler indefinitely because of this test.The defer makes sense for VM cases, where on charm refresh, all units will set it state to
readyon theupgrade-charmhandler. On K8s, only the upgrading unit will receive theupgrade-charmevent, and if the leader unit is not the upgrading unit, thecluster_statewill remain in the recovery state.Deferring the
on_upgrade_changedindefinitely will prevent theupgrade_stackbeing popped, and a subsequentresume-upgradewill set the wrong partition value, staling the rollback process.