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.
There are two problems with doing so as part of individual
functional tests:
1) If the application already have the value set the test will
time out waiting for a change that will never be made.
2) python-libjuju ``set_config`` call requires values to be
``str`` regardless of their actual type. Pairing this fact
with the requirement to use the actual type when comparing
values before attempting to set them makes this very confusing
and error prone.
juju/python-libjuju#388openstack-charmers/zaza#348
Use the ``config_change`` helper instead.
When applying configuration to a model the helpers will compare
settings already set to what is being attempted set to be able to
accurately predict model behaviour.
When passing ``bool`` values as ``str`` this does not work and it
may lead to unwanted behaviour depending on the model state at the
time the test runs.
At present we may start interrogating the model for a result of
a change made by the functional test before all units of the
application have started executing.
Commit 55fc718f98 moved a QoS data
plane test from Neutron Gateway tests to the Neutron API tests.
This was probably done because the Neutron API charm gate was
doing end to end tests for all deployment topologies.
On the back of splitting out the data plane tests from Neutron API
gate to the respective data plane charms we need to move this
test back where it belongs.
Apparantly the Neutron Open vSwitch test class have its own
variant of this test already that will be executed by the
neutron-openvswitch charm gate.
Validate settings for existing and configured ovs-use-veth settings.
Verify the charm goes into a blocked state if they conflict.
Partial-Bug: #1831935
It would be awesome if the first iteration of a ARP lookup, ICMP
echo and ICMP reply on a newly created instance was always
successful. Sadly this is not the reality.
This is useful for validating deployments with OVN where it is not
required to have external networking attached to every chassis.
Any chassis that does not have external networking directly
attached will forward traffic destined for the external network
through a tunnel to a chassis that does.
Frode Nordahl
Alex Kavanagh
Aurelien Lourot
Liam Young
Dmitrii Shcherbakov
Alex Kavanagh
David Ames
arif
Jose Guedez
Chris MacNaughton