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.
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
Liam Young
David Ames
Przemysław Lal
Frode Nordahl
Alex Kavanagh
Aurelien Lourot
Dmitrii Shcherbakov
Alex Kavanagh
arif
Jose Guedez