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
Add Python 3.8 env in Travis CI test matrix.
At present the pinning of flake8 disallows running of lint on
Python 3.8 systems.
Update flake8 ignore-list to ignore W504 instead of W503, the PEP
guidance is that either is ok, but there must be local consistency.
There are more occurences of binary operator before line-break
than after in this repository, and we have also chosen to ignore
W504 in most of our other repositories.
Previous attempts to fix LP Bug#1784083 added a workaround (commit
820ed808) which is being removed here.
The root cause seems to be upstream in the dragent. It may never have
been envisioned to run the agent by itself the way the charm does.
So that even if neutron-api completes its amqp relation first,
neutron-dynamic-routing can still see
oslo_messaging.exceptions.MessagingTimeout errors. Some operation
must occur against neutron before dragent is truly ready. i.e. some post
deploy openstack command. So it is outside the purview of the charm.
This change adds a service restart late.
Partial-Bug: #1841459
Add zaza.openstack.utilities.juju.get_subordinate_units to get a list
of all subordinate units associated with units in unit_list.
Subordinate can be filtered by using 'charm_name' which will only
return subordinate units which have 'charm_name' in the name of the
charm.