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.
* Check blocked ovn-chassis units with bad config
LP bug#1919481 [0] needs to have a func-test to check if units can
handle bad bridge-interface-mappings configuration and set units
workload to block state and return to active state with good config.
[0] https://bugs.launchpad.net/charm-ovn-chassis/+bug/1919481
* Changing test_wrong_bridge_config to use config_change
Instead of using block_until_unit_wl_status, change the test_config
to be able to check blocked state for ovn-chassis units
Co-authored-by: Aurelien Lourot <aurelien.lourot@canonical.com>
After zaza#451 Zaza's application readiness detection
has been improved, which now exposes issues from the
past that were hidden. In other words, we were relying
on a bug on Zaza's side and need to get this straight.
* 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
Frode Nordahl
Gabriel Angelo Sgarbi Cocenza
Aurelien Lourot
Liam Young
Xav Paice