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 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
Add a work around for Bug #1964117. To ensure that this is only
a temporary measure the fix is tied to specific OpenStack releases
and package versions.
This change drops the use of AssertionError in favor of
LoadBalancerUnexpectedState that was introduced by commit acaeb62 which
stopped retrying on AssertionError.
A missing 's' on importing the zaza.openstack.utilities.exceptions in
the octavia tests are causing gate tests to fail. This fixes the import
to point at the right module.
Fixes#721
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
* Stop retrying if LB provisioning status reached ERROR
The method `wait_for_lb_resource()` retries for 15m while the load
balancer could have reached to ERROR during the provisioning in the
first few minutes, this approach makes the testing take longer for no
reason.
This change makes the ERROR state in provisioning_status final and
abort raising a ValueError() exception.
More details of the provisioning_status possible states can be found at:
https://docs.openstack.org/api-ref/load-balancer/v2/#provisioning-status-codes
* Use LoadBalancerUnexpectedState and LoadBalancerUnrecoverableError.
Drop the (re-)use of AssertionError and ValueError to identify when a
load balancer status is in a state where the test needs to retry or
break and fail respectively.
This change introduces 2 new exceptions to be explicit of what the code
is trying to do.
- LoadBalancerUnexpectedState is raised when the status of the load
balancer is in a state different from the one requested by the caller,
but said state can be considered as transitory.
- LoadBalancerUnrecoverableError is raised when the status of the load
balancer is in ERROR state and said state is final for the
proviniong_status property, hence retrying only delays the failure.
Frode Nordahl
Chris MacNaughton
Luciano Lo Giudice
Liam Young
Billy Olsen
James Page
Dmitrii Shcherbakov
coreycb
Aurelien Lourot
Felipe Reyes
Pedro Castillo
Billy Olsen