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