* Updates to concurrent series upgrade
Updates to make it run more in parallel and spend less time waiting on
the whole model when updating machines.
* Make the concurrent series upgrade tests work
This is a number of changes to get the concurrent (here called
'parallel' historically) series upgrade tests to work. A number of
changes were required which included limiting the number of concurrent
async co-routines (futures) that could be run as with large models it
hits the limits of the Py3 runtime.
* Fix the tests and change pause order in maybe_pause_things
Due to an additional model helper call, an additional model AsyncMock is
required. Also the pause order had changed, and this is restored to
ensure the original design is retained (for pause order).
Clean up some commented out code and sort out a few PEP8 errors.
* Update comment to reflect code (3 -> 4)
* Fix tests that fail on bionic but pass on focal
Essentially, asyncio.gather has different behaviour on bionic that
focal. Although this doesn't affect testing, it does affect the unit
tests. These changes are simply to normalise the behaviour of unit
tests on focal and bionic.
The biggest change is that the upgrade_groups() is a list of tuples ...
[()] ... rathern than a collections.OrderedDict(). This tends to make
more sense as they are processed in order and don't actually need to be
indexed.
Also excludes easyrsa (as it's not an upgrade target) and adds a
"Database Services" which upgrades mysql or percona FIRST before moving
on to rabbitmq and other stateful services. This is because some charms
really need to talk to mysql if one of the other stateful services does
a relation changed hook. This makes it more likely that the system will
ugprade correctly.
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
Alex Kavanagh
Alex Kavanagh
Chris MacNaughton