aodhclient is pinned at 1.4.0 and pyparsing needs to be pinned at <
3.0.0 to work with. Note zaza also pins pyparsing as many, many modules
use pyparsing and if zaza gets installed first ti might break pip
resolution.
distro-info hasn't been maintained for 8 years and pip is
now failing to fetch it on Python 3.8.
This dependency seems to have been introduced by accident
in 22e7ffc.
See https://github.com/openstack-charmers/zaza-openstack-tests/issues/530
Issue:
Python 3.5. is deprecated/EOL
Py35 is used on Xenial
Xenial is used as the test platform to run tests.
lxml is used by zaza-openstack-tests for the SAML assertions (because they are XML)
lxml > 4.6.2 releases are after py3.5 has been deprecated/EOL.
Therefore, no wheels are now built for lxml for py35.
Thus there is a binary dependency to build lxml for testing
A couple of changes here:
* Ensure that the post-upgrade-hook runs BEFORE the config-changed to
set the openstack-origin/source back to distro. The former behaviour
breaks keystone quite badly.
* Ensure that the charm name is used, as discovered from the model, for
rabbitmq-server and percona-cluster to cope with different names for
the application in the model vs the charm name from the charm-store.
* Check whether the machine needs to be rebooted after the dist-upgrade
(before the do-release-upgrade), and reboot the machine first.
Otherwise, do-release-upgrade will fail.
python-libjuju was broken at 2.8 and thus zaza and zaza-openstack-tests
needed to be pinned to < 2.8. This patch releases that so that the
latest versions of libjuju are used in testing. This may get pinned
again before the next release window.
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.
Providing a policy.d test for Octavia is a bit more complicated as the
obvious policy is just to prevent listing of load balancers;
unfortunately it doesn't work in the upstream, as the code doesn't check
the policy in octavia. However, "showing" an load balancer does involve
a policy check and so the test is more complicated than 'normal' policy
tests in that a resource is created, then the policy override is checked
and then the resource is deleted.