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 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.
When pgrep_full=True is used, the resulting pgrep can match
more binaries than expected if the search pattern isn't specific
enough. This change makes the search patterns more specific
in order to only match the expected binaries.
Closes-Bug: #1933338
Pyyaml>=6.0 requires to pass the Loader arg to yaml.load(), switching to
yaml.safe_load() recovers the old and expected behavior.
https://github.com/yaml/pyyaml/pull/561
Closes-Bug: #1951650
This adds a new setup function that will setup a VLAN provider network.
It can be called by tests.yaml after basic_overcloud_network:
- zaza.openstack.charm_tests.neutron.setup.basic_overcloud_network
- zaza.openstack.charm_tests.neutron.setup.vlan_provider_overcloud_network
Do not run the deferred hooks action for neutron gateway as it is
not needed and will end in an action error.
Tested locally here: https://paste.ubuntu.com/p/cSmgxmrTr4/
This closes issue #553
* Add ovn-chassis test
* Yet another refactor to reduce the amount that implementations need to override.
* Add ovn dedicated chassis support
* Fix race with checking wlm
* Add support for running NeutronOvsVsctlTest against any charm and not
only charm-neutron-gateway.
* Add new test case for charm-neutron-gateway and charm-neutron-openvswitch to
verify correct handling of conflicting ext-port and data-port configurations.
Signed-off-by: Przemysław Lal <przemyslaw.lal@canonical.com>
When on MAAS support doing charm based configuration of OVS by
retrieving MAC address of ports attached to external network
from MAAS.
Note that we should extend the MAAS support to also work with
deployments where MAAS does the OVS configuration for us.
A recent change introduced a configuration option in the
./tests/test.yaml file (default location) which allows juju wait to be
used rather than waiting on various workload messages. This,
unfortunately, breaks mojo tests as they don't use a tests.yaml. This
change refactors that code, and enables a 'use_juju_wait' to be passed
into the relevant functions, and a new command line option (default
true) to disable using juju wait.
Adjust NeutronNetworkingTest to optionally run tearDown and
re-use existing instances on subsequent runs.
tearDown is controlled through a key under the `tests_options`
dictionary in tests.yaml.
Useful for morphing a deployment and then validating connectivity
for existing instances afterwards.