Because the OpenStack charms re-render their config
whenever things are incorrect, we can accept any new
package defaults as a part of the upgrade and
resolve incorrect config after the upgrade
By including pre and pos-application functions, charm
series upgrades can be handled in a more generic way,
even when they require running additional actions
before a unit is upgraded, or after the whole application
is upgraded.
Updating each machine in a fully self-contained way makes
it easy to add per-machine and (possibly) per-application
post-upgrade function calls. This still performs the actual
series upgrades fully in parallel but will, for example,
start the do-release-upgrade on one unit while another is
still performing the initial dist-upgrade
Chris MacNaughton