Add support for tests having a resource_cleanup method. Whether this
is run or not is dictated by the class variable
'run_resource_cleanup'. By default this will be True but any test
can switch it to False so that resources created by the tests are
preserved. Helpful for debugging failures.
FWIW future work might include automatically disabling resource
cleanup if a test fail is detected.
Providing a policy.d test for Octavia is a bit more complicated as the
obvious policy is just to prevent listing of load balancers;
unfortunately it doesn't work in the upstream, as the code doesn't check
the policy in octavia. However, "showing" an load balancer does involve
a policy check and so the test is more complicated than 'normal' policy
tests in that a resource is created, then the policy override is checked
and then the resource is deleted.
The difference in how openstack-dashboard and every other service uses
policies continues to create special cases. This set of fixes deals
with some more of those differences.
* Addition of the (incomplete) openstack-dashboard test.
* Modification of other charm policyd override tests to support
multi-file policy overrides resource ZIP.
The current implementation may miss waiting for config change to
actually happen as it in some circumstances jumps to waiting for a
idle state prior to the model executing anything.
Add a wait for agent status `executing` immediatelly after config
change to avoid this.
Fixes#123
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.
Increase wait attempts for availability of volume created from image
in CephRBDMirrorTest. This is taking longer as of Nautilus due to
switch to using juju storage backed by undercloud cinder taking
longer than prior method of directory-backed OSD devices.
We are stuck with juju_wait until we figure out how to deal with
all the non ['active', 'idle', 'Unit is ready.'] workload/agent
states and msgs that our mojo specs are exposed to.
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.
