This PR ensures that the SAML tests are using a fully valid IDP
metadata (Ceph's dashboard doesn't report its validity until SAML
features are used), as well as using TLS in the requests, in addition
to some cleanups here and there.
The neutron ``basic_overcloud_network`` setup job performs both
undercloud and charm configuration prior to configuring the
overcloud network. The undercloud and charm configuration steps
are useful outside the context of OpenStack Neutron.
Split undercloud and charm setup into a new configure step.
Update CPU topology flavor advice.
The example currently listed would create a two socket CPU with
only one NUMA node, which is a invalid configuration which leads
to undefined results.
Instead list two examples one with a single socket for simpler
end to end tests and a two socket two numa node example for more
advanced low level tests.
The test blindly reverts the ``bridge-interface-mappings``
configuration to an empty string, which would be the wrong thing
to do if it was previously set up by a test configure step.
The test also does not properly populate target_deploy_status and
the test will always wait for the next update status to run,
which may take several minutes, before completing.
The test will prepare hypervisor units in virtual machines by
enabling hugepages configuration and rebooting them and
subsequent required runtime changes. If the hypervisor units
are physical machines the test assumes they already have
received the appropriate configuration from the bare metal
provisioning system.
Launch nested instance using flavor that enables hugepages and
attach it directly to the external network and perform
connectivity tests.
After a successful test the hypervisor units are brought back
to their original state to not influence subsequent tests.
Allow launching an instance and attaching it directly to the
external provider network. This is useful in its own right and
is also a requirement in order to successfully test some
configurations.
The metric test is too strict and fails if it finds a metric that
is not explicitly listed in the test. Given the test does check
that the expected metrics are present there seems not need to fail
if a new one has added upstream.
The zaza and zaza-openstack-tests project are currently installed
within the same package. A side effect of that is that the
zaza/__init__.py from zaza is overwritten by the one in
zaza-openstack-tests.
We ought to find a better way of doing this but we're currently
blocked on using zaza + zaza-openstack-tests on systems with
Python 3.10 installed, and updating this file unblocks us.
Update zaza/__init__.py from openstack-charmers/zaza@c48c955ef7
There appears to be a race condition between the loop device creation
and its actual usage. In order to prevent that, this PR setups these
devices during the test initialization instead of right before using
them in the 'add-disk' tests.
There are some Ceph charms that do not install the
openstack-release package, so fall through to the
dict to identify which release they are on, and can
fail with a KeyError when not finding a matching
entry for Pacific and Quincy.
* Check the charm config options when constructing the expected
cinder.conf contents. This makes the tests less brittle when
bundles are changed.
* Only check the volume backend name for netapp as the host part
is now the cinder units hostname
