This event is triggered when an operator runs juju upgrade-series <machine> prepare ... from the command line. Read here to learn more about the series upgrade process. This event hook allows charm units on the machine being upgraded to do any necessary tasks prior to the upgrade process beginning (which may involve e.g. being rebooted, etc.).
pre-series-upgrade -> (events on pause until upgrade completes)
Notably, after this event fires and before the post-series-upgrade event fires, juju will pause events and changes for all units on the machine being upgraded. There will be no config-changed, update-status, etc. events to interrupt the upgrade process until after the upgrade process is completed via juju upgrade-series <machine> complete.
Leadership is pinned during the series upgrade process. Even if the current leader dies or is removed, re-election will not occur for applications on the upgrading machine until the series upgrade operation completes.
@billy-olsen at @tmihoc’s request, I added some basic info to the docs for this hook. I know that the OpenStack team uses this (and the post-series-upgrade hooks. Is there anything that you or your team can add to either of the docs?
I think we need a bit more detail from the Juju team, please, as what happens to the unit when the principle charm is going to receive the pre-series-upgrade hook. e.g.:
What happens with subordinates?
Do subsequent hooks get queued up (e.g. if a pre-series-upgrade hook is done, and then another unit is removed from the same application before the post-series-upgrade hook is run, when do the peer relations run for this unit and any other units). Is update-status still run for all the subordinates / peer units in the application.
If the wrong unit is picked for series upgrade, can it be cancelled?
What happens with config-changed between pre-series-upgrade and post-series-upgrade?
The scope for series-upgrade hooks is the machine. All units on the machine targeted for upgrade get the event, regardless of their primary/secondary status.
No hooks are run between the completion of the pre-upgrade hook and the completion of the post-upgrade hook. They are not queued, but nor is the server-side state updated. It is anticipated that after completion, the local/remote state difference will cause all the appropriate hook invocations.
Leadership of applications affected by a series-upgrade is “pinned” at this time, so removal of a unit that happened to be the leader (from another machine of course) would only cause re-election once completed.
You can issue the complete sub-command without actually running do-release-upgrade, which should restore the normal machine (and its units’) state.
config-changed will not run for the machine’s units in this window.
